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Foreword 



This European Telecommunication Standard (ETS) has been produced by the Radio Equipment and 
Systems (RES) Technical Committee of the European Telecommunications Standards Institute (ETSI). 
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"General network design". 
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"Air Interface (Al)". 
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"Security". 
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1 Scope 

This ETS defines the Trans-European Trunked Radio system (TETRA) supporting Voice plus Data (V+D). 
It specifies the air interface, the inter-working between TETRA systems and to other systems via 
gateways, the terminal equipment interface on the Mobile Station (MS), the connection of Line Stations 
(LSs) to the infrastructure, the security aspects in TETRA networks, the management services offered to 
the operator, the performance objectives, and the supplementary services that come in addition to the 
basic and tele-services. 

This part of this ETS applies to the TETRA V+D radio air interface. 

It establishes the TETRA general network design: 

it defines and specifies the circuit mode and packet mode reference points for the MS, LS and 
switching and management infrastructure; 

it defines and specifies a model of the air interface protocol stack where the different functions of 
layers and sublayers are listed based on ISO 8473 [13] and ISO 8208 [11] methodology; 

it defines and specifies the TETRA addressing and identities and their organisation in groups 
corresponding to the different functions; 

it defines and specifies the functions provided by the circuit mode teleservices used for speech and 
basic services used for data transfer; 

it defines and specifies the functions related to the management of the users' mobility across 
networks and inside a network including roaming and migration; 

it defines and specifies the functions related to the transport of short data messages as a service 
specific to TETRA; 

it defines and specifies the functions related to the support of connection oriented packet data 
service in TETRA; 

it defines and specifies the functions related to the support of connectionless packet data service in 
a way specific to TETRA; 

it defines and specifies the supplementary services that mainly extend the capabilities of the circuit 
mode basic and teleservices; 

in-informative annexes, it illustrates the various possibilities of individual circuit mode call scenarios 
and provides guidance on priority concepts for packet data and circuit mode services and on the 
service quality. 

NOTE: This part of this ETS may, by its nature as a general design statement, require 
updating when later parts of the ETS are completed (in order to avoid any non- 
alignment). If a discrepancy occurs between this part and any other part of this ETS, 
then the other part will take precedence. This part will be updated at a frequency 
consistent with maintaining the integrity of the ETS as a whole. 

2 Normative references 

This ETS incorporates by dated and undated reference, provisions from other publications. These 
normative references are cited at the appropriate places in the text and the publications are listed 
hereafter. For dated references, subsequent amendments to or revisions of any of these publications 
apply to this ETS only when incorporated in it by amendment or revision. For undated references the latest 
edition of the publication referred to applies. 

[1] CCITT Recommendation E.163 (1988 Blue Book): "Numbering Plan for the 

International Telephone Service". 



[2] 



CCITT Recommendation E.164 (1988 Blue Book): "Numbering Plan for the 
ISDN Era". 
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[3] CCITT Recommendation E.212 (1988 Blue Book): "Identification Plan for Land 

Mobile Stations". 

[4] CCITT Recommendation E.213 (1988 Blue Book): "Telephone and ISDN 

Numbering Plan for Land Mobile Stations in Public Land Mobile Networks 
(PLMN)\ 

[5] CCITT Recommendation 1.130: "Method for the characterization of 

telecommunication services supported by an ISDN and network capabilities of 
an ISDN". 

[6] CCITT Recommendation 1.411: "ISDN User-Network Interfaces - Reference 

Configurations". 

[7] CCITT Recommendation V.110: "Support of Data Terminal Equipments (DTEs) 

with V-series type Interfaces by an Integrated Services Digital Network (ISDN)". 

[8] CCITT Recommendation X.121 (1988): "International Numbering Plan for Public 

Data Networks". 

[9] CCITT Recommendation X.213: "Network Service Definition for Open System 

Interconnection for CCITT applications". 

[10] CCITT Recommendation X.219: "Remote Operations: Model, Notation and 

Service Definition". 

[11] ISO 8208: "X.25 packet level protocol for Data Terminal Equipment". 

[12] ISO 8348: "Information processing systems - Data communications-Network 

service definition". 

[13] ISO 8473: "Protocol for providing the connectionless mode network service". 

[14] ISO 8878: "Use of X.25 to provide the OSI connection mode network". 

[15] ECMA-165 PTN: "Generic Functional Protocol for the support of Supplementary 

Services". 

[16] ETR 086: "Radio Equipment and Systems (RES); Trans-European Trunked 

Radio (TETRA) systems; Technical requirements specification". 

[17] ETS 300 392-2: "Radio Equipment and Systems (RES); Trans-European 

Trunked Radio (TETRA); Voice plus Data (V+D); Part 2: Air interface". 

[18] prETS 300 392-10: "Radio Equipment and Systems (RES); Trans-European 

Trunked Radio (TETRA); Voice plus Data (V+D); Part 10: Supplementary 
services". 

3 Definitions, symbols and abbreviations 
3.1 Definitions 

For the purposes of this ETS, the following definitions apply: 

announced cell re-selection: Cell re-selection where MS-MLE informs the SwMI both in the old cell 
(leaving cell) and in the new cell (arriving cell) that cell change is performed. There are three types of 
announced cell re-selection: 



type 1: 



the MS-MLE knows the new cell and the traffic channel allocations on the cell before deciding 
to leave its serving cell; 
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type 2: 

the MS-MLE knows the new cell before changing to it, but does not know the channel 
allocation on the new cell in advance; 

type 3: 

the MS-MLE does not know the new cell before changing to it. The old cell is only informed 
by the MS-MLE that it wants to change cell. 

attached: A MS is said to be attached to a cell when the MS is camped and registered on the cell. The 
MS may be in idle mode (i.e. not actively processing a transaction) or in traffic mode (i.e. actively 
processing a transaction in reception and/or in transmission). It is the MM which decides when a MS is 
said to be attached. 

authentication: A function which allows the infrastructure to check that a MS is valid to operate in the 
system or which allows a MS to check that the infrastructure is valid to operate in. 

background measurement: Measurement performed by the lower layers while maintaining current 
service toward the service users, i.e. MS-MLE. 

bearer service: A type of telecommunication service that provides the capability for the transmission of 
signals between user-network interfaces. 

bundle: A collection of ITCs which utilises the same scenario over the inter system interface, 
call: A complete information exchange between two or more parties. 

call transaction: All of the events associated with one continuous transmission of information during a 
call (including control signalling). A call consists of one or more call transactions. 

NOTE 1: In a half-duplex call, the call consists of a sequence of unidirectional transactions. 

camped: A MS is said to be camped on a cell when the MS is synchronized on the cell BS and has 
decoded the Broadcast Network CHannel (BNCH) of the cell. The synchronization procedure is performed 
by the MAC and the interpretation of the network information from the BNCH (V+D) is performed by a 
procedure in the MLE. It is the MLE which decides when a MS is said to be camped on a cell. 

cell re-selection: The act of changing the serving cell from an old cell to a new cell. The cell re-selection 
is performed by procedures located in MLE and in the MAC. When the re-selection is made and possible 
registration is performed, the MS is said to be attached to the cell. 

cell-id: Characterized as the channel number of the main carrier on the cell. 

constant delay service: A network service (NS) where the transit delay of the NSDUs between the 
network connection endpoints remains constant for the duration of the connection. 

direct set-up signalling: A signalling procedure where immediate communication can take place 
between the calling and the called users without the alerting process and without an explicit response from 
the called user that he has answered. 

external calls: A call where only one of the parties (either the source or the destination) is in a TETRA 
network. The other party is in a non-TETRA network. 

foreground measurement: Measurements performed by the lower layers while employing the whole 
capacity, e.g. no concurrent service is maintained. 

functional group: A set of functions which may be needed in TETRA Land Mobile Network (LMN) access 
arrangements. In a particular access arrangement, specific functions in a function group may but need not 
be present. 
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NOTE 2: Specific functions in a functional group may be performed in one or more pieces of 
equipment. 

Grade Of Service (GOS): Refers to certain traffic engineering variables which may be used to provide a 
measure of the adequacy of a Network Service (NS) under specified conditions. 

home network: A network where a subscriber has a direct subscription. This means that a subscriber 
identity has been allocated in advance of any network access. 

initial cell selection: The act of choosing a first serving cell to register in. The initial cell selection is 
performed by procedures located in MLE and in the MAC. When the cell selection is made and possible 
registration is performed, the MS is said to be attached to the cell. 

internal calls: A call where both the source (the calling party) and the destination (the called party) both 
lie in a TETRA network domain. 

interrupted measurement: Measurements performed by the lower layers interrupting current services. 

inter-TETRA call: A call where source and destination are in different TETRA networks. 

Inter-TETRA Connections (ITCs): ITCs are provided by the Intervening Networks (IVNs) at the Inter- 
System Interface (ISI) and terminate at interfaces at C reference points. They may be grouped into 
bundles, each connecting to a specific type of IVN. Bundles, in turn, may comprise more than one 
interface between the TETRA SwMI and the IVN. 

Inter-TETRA Links (ITLs): ITLs are provided by the Intervening Network Adaption (INA) and terminate at 
interfaces at the Q reference point in the ISI. An ITL is characterised by its ITL identity which corresponds 
to the instance of the Q reference point. The ITL comprises one (1) DQ channel and a number of UQ 
channels each of them having certain channel characteristics. 

Intervening Network (IVN): IVN is the network which is used to interconnect two TETRA SwMIs at the 
ISI. The network may be of the following types: 

dedicated transmission system e.g. PCM; 

permanent circuit switched e.g. PSTN and ISDN; 

on-demand circuit switched e.g. PSTN and ISDN. 

inter-working unit: One or more items of equipment or a part of an item of equipment whose operation 
provides a network relay function; that is a real system that receives data from one correspondent network 
entity and forwards it to another correspondent network entity. Such equipment may be integrated into a 
real sub-network which is being interconnected. 

intra-TETRA call: A call where both source and destination are in the same TETRA network sub-domain. 

Location Area (LA): The area within radio coverage of a base station or group of base stations within 
which a MS is allowed to operate. 

LXX SAP: Any or all of the following SAPs: LCMC SAP, LCO SAP, LSCL SAP. 

message trunking: A method of traffic channel organisation where each traffic channel is permanently 
allocated for the complete duration of the call, which may include several separate call transactions 
(several pressel activations by separate terminals). The channel is only de-allocated if the call is (explicitly) 
released or if a time-out expires (see also transmission trunking, quasi-transmission trunking). 

migration: The act of changing to a new LA in a network (either with different MNC and/or MCC) where 
the user does not have subscription (ITSI) for that network. 

Mobile Network Identity (MNI): The identity that is broadcast by all TETRA base stations to uniquely 
identify the network. 
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Mobile Station (MS): A physical grouping that contains all of the mobile equipment that is used to obtain 
TETRA services. By definition, a MS contains at least one Mobile Radio Stack (MRS). 

monitoring: The act of measuring the power of neighbour cells and calculating the path loss parameter 
C2 based upon information on neighbour cells broadcast by the serving cell (see ETS 300 392-2 [17], 
clause 10). 

network: A collection of subscriber terminals interconnected through telecommunications devices. 

Network SAP Address (NSAP Address): Addresses that belong to other (non-TETRA) addressing 
domains. These other domains include ISDN, PSTN and PDN domains. 

nominal radio coverage area: The nominal radio coverage area is the geographical area over which the 
radio transmission performance exceeds a defined level. 

NOTE 3: The boundary of the nominal radio coverage area is defined by a Bit Error Ratio (BER) 
contour as defined in ETS 300 392-2 [17], clause 6. 

on/off hook signalling: A signalling procedure which includes an alerting process to the called user. The 
calling user should wait for an explicit response from the called user that he has answered before the call 
can be set-up. 

Quality of Service (QoS): Refers to certain characteristics of a Network Connection (NC) as observed 
between the NC endpoints which are attributable solely to the Network Service (NS) provider. 

quasi-transmission trunking: A method of traffic channel organisation where each traffic channel is 
allocated for the each call transaction (while the pressel is activated) and in addition the channel 
de-allocation is delayed for a short period at the end of the transaction (after the pressel release). During 
this "channel hold-time", the channel allocation may be re-used for a new call transaction that is part of the 
same call. A delayed channel de-allocation procedure will apply at the end of each transaction. 

R0: The reference point within the Mobile Terminating Unit (MTU) that corresponds to the top of the MRS 
not including the routing. R0 acts as the network service boundary and exists in all MTUs. 

R1: The reference point between packet mode Terminal Equipment (TE2) and the MTU (MTU2). There 
may be several alternative interface protocols at R1 , including existing packet mode standards. 

R2: The reference point at the TETRA air interface. 

R4: The reference point for a character mode terminal equipment (TE3) connected to a Packet Assembler 
and Disassembler (PAD). There may be several alternative interface protocols at R4, including existing 
PDN standards. 

R5: The reference point between the Network Management Unit (NMU) and the TETRA network. 
R6: The reference point between one TETRA network and another TETRA network. 
R7: The reference point between one TETRA network and a non-TETRA packet data network. 
R10: A logical reference point equivalent to R0. 

ranking: A procedural method of listing cells in descending order from the most suitable for 
communication to the least suitable for communication. The method comprises multiple calculations of C 4 
parameters and C 3 parameters, defined in ETS 300 392-2 [17], clause 10. As inputs to the ranking 
procedure are: 

outputs from the monitor process (e.g. C 2 parameters); 
outputs from the scanning process (e.g. C, parameters); 
network parameters received in the MLE broadcast. 
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reference configuration: A conceptual configuration useful in identifying various possible physical 
access arrangements to a TETRA LMN. 

Two concepts are used in defining reference configurations: 

reference points; and 

functional groups. 

NOTE 4: Physical interfaces that do not correspond to a reference point will not be described in 
the TETRA ETS. 

reference point: A conceptual point dividing functional groups. In a specific access arrangement, a 
reference point may correspond to a physical interface between pieces of equipment, or there need not be 
any physical interface corresponding to the reference point. Physical interfaces that do not correspond to 
a reference point (e.g. transmission line interfaces) will not be the subject of TETRA LMN interface 
recommendations. 

registration: The act of becoming an active and recognised TETRA user by exchange of ITSI with the 
SwMI. 

relaying: This function enables a network entity to forward information received from one correspondent 
network entity to another correspondent network entity. 

roaming: The act of changing LA within a network of the same MNC/MCC, and for which the user has a 
valid registration (ITSI). 

routing: This function determines an appropriate route between network addresses. 

scanning: The act of measuring the power of neighbour cells and calculate the path loss parameter C, 
based upon the information on the neighbour cells broadcasted by the neighbour cells themselves (see 
ETS 300 392-2 [17], clause 10). 

Search Area (SA): An area comprising all LAs where a MS may search for service. The search area is 
considered to be defined at subscription. Some means of changing the search area during operation could 
be considered. However, the method of loading SA into the MS and to change it accordingly is outside the 
scope of the TETRA ETS. 

segmentation: The act of generating two or more derived PDUs from an initial or derived PDU. 

service coverage area: The percentage of the nominal radio coverage area over which a specified grade 
of service and quality of service is maintained for a given service type. 

NOTE 5: A particular service coverage area is specific to one service and one network. 

serving cell: The cell that is currently providing service to the MS. 

Short Subscriber Identity (SSI): The network specific portion of a TSL A SSI is only unique within one 
TETRA sub-domain (one TETRA network). 

NOTE 6: There are four different types of SSI (see subclause 7.2.3): 

a) Individual SSI (ISSI); 

b) Group SSI (GSSI); 

c) Alias SSI (ASSI); 

d) Un-exchanged SSI (USSI). 

sub-network: A collection of equipment's and physical media which forms an autonomous whole and 
which can be used to interconnect real systems for purpose of communication. 
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supplementary service: A service which modifies or supplements a bearer service or a teleservice. A 
supplementary service cannot be offered to a customer as a stand-alone service. It should be offered in 
combination with a bearer service or a teleservice. 

surveillance: The process of monitoring the quality of the radio link to the serving cell. 

TETRA Equipment Identity (TEI): An electronic serial number that is permanently embedded in the 
TETRA equipment. A TEI is embedded in both MSs (in the MT) and in LSs (in the NT). 

TETRA Management Identity (TMI): The network address that allows the operator to address a 
particular Mobile Termination (MT) or Line Termination (LT). TMIs are assigned to a particular piece of 
equipment by the network operator. TMIs are unique in all TETRA networks. 

NOTE 7: The management entity has no functionality in this ETS. 

TETRA Subscriber Identity (TSI): A global TETRA network address that is used to identify an individual 
or a group subscriber within the domain of all TETRA networks. A valid TSI refers to a TSI that has been 
allocated by the network where it is being used (see figure 25 for addressing domain). 

TLC-SAP: Management SAP. The way of modelling layer-to-layer communication for management and 
control purpose. 

transmission trunking: A method of traffic channel organisation where each traffic channel is individually 
allocated for each call transaction (for each activation of the pressel). The channel is immediately de- 
allocated at the end of the call transaction, subject to unavoidable protocol delays (see also message 
trunking, quasi-transmission trunking). 

unannounced eel! re-selection: Cell re-selection where the MS-MLE does not inform the old cell 
(leaving cell) that it intend to change to a new cell. Only the new cell (arriving cell) is informed about the 
MS-MLE. 

undeclared cell re-selection: Cell re-selection where the MS-MLE does not inform the old cell (leaving 
cell) nor the new cell (arriving cell) that cell change is performed. 

variable delay service: A Network Service (NS) where the transit delay of the NSDUs between the 
Network Connection (NC) endpoints does not remain constant for the duration of the connection. 

visited network: A network where a subscriber has an indirect subscription. This means that a valid 
subscriber identity is only allocated as part of the first network access. 

This ETS also makes use of the standard terms used in ISO in particular: 

logical channel; 

end system; 

access point; 

service primitive; 

Data Terminal Equipment(DTE). 
3.2 Symbols 

For the purposes of this ETS, the following symbol applies: 



» 



Possible physical interfaces. 
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3.3 Abbreviations 



For the purposes of this ETS, the following abbreviations apply: 



Al-n 


Air Interface layer n 


AL 


Ambience Listening 


AoC 


Advice of Charge 


AP 


Access Priority 


AP1 


Access Point for Bearer Services at S reference point 


AP2 


Access Point for Bearer Services at R reference point 


AP3 


Access Point for Teleservices 


AS 


Area Selection 


ASSI 


Alias Short Subscriber Identity 


ATSI 


Alias TETRA Subscriber Identity 


BIC 


Barring of Incoming Calls 


BOC 


Barring of Outgoing Calls 


BS 


Base Station or Base Station (Cell) 


CAD 


Call Authorized by Dispatcher 


CC 


Call Control 


CCBS 


Call Completion to Busy Subscriber 


CCNR 


Call Completion on No Reply 


CFB 


Call Forwarding on Busy 


CFNRc 


Call Forwarding on Mobile Subscriber Not Reachable 


CFNRy 


Call Forwarding on No Reply 


CFU 


Call Forwarding Unconditional 


CL 


ConnectionLess 


CLIP 


Calling Line Identification Presentation 


CLIR 


Calling/connected Line Identification Restriction 


CMCE 


Circuit Mode Control Entity 


CO 


Connection Oriented 


COLP 


Connected Line identification Presentation 


CONP 


Connection Oriented Network Protocol 


CR 


Call Report 


CRT 


Call Retention 


CW 


Call Waiting 


DGNA 


Dynamic Group Number Assignment 


DL . 


Discreet Listening 


DSD 


Destination Short Data 


DSDA 


Destination Short Data Agent 


DSE 


Dialogue Service Element 


ESN 


Electronic Serial Number 


FAC 


Final Assembly Code 


GoS 


Grade of Service 


GSM 


Global System for Mobile communications 


GSSI 


Group Short Subscriber Identity 


GTSI 


Group TETRA Subscriber Identity 


HOLD 


Call HOLD 


IC 


Include Call 


IGSD 


Incoming Gateway Short Data 


INA 


Intervening Network Adaption 


ISD 


Inter-system Short Data 


ISDN 


Integrated Services Digital Network 


ISI 


Inter-System Interface 


ISSI 


Individual Short Subscriber Identity 


ITC 


Inter TETRA Connection 


ITL 


Inter TETRA Links 


ITSI 


Individual TETRA Subscriber Identity 


IVN 


Intervening Network 


LE 


Late Entry 


LMN 


Land Mobile Network 


LS 


Line Station or Line-connected Station 


LSC 


List Search Call 


MAC 


Medium Access Control 
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MCC 


Mobile Country Code 


MLE 


Mobile Link Entity 


MM 


Mobility Management 


MNC 


Mobile Network Code 


MNI 


Mobile Network Identity 


MS 


Mobile Station 


MT 


Mobile Termination (short form for MTU) 


MTO 


Mobile Termination type 0 


MT2 


Mobile Termination type 2 


MTU 


Mobile Termination Unit 


NC 


Network Connection 


NS 


Network Service 


NSAP 


Network Service Access Point 


NSDU 


Network Service Data Unit 


NT 


Network Termination 


OGSD 


Outgoing Gateway Short Data 


OSD 


Originating Short Data 


OSDA 


Originating Short Data Agent 


OS I 


Open Systems Interconnect 


PC 


Priority Call or Protocol Control 


PDN 


Packet Data Network 


PDU 


Protocol Data Unit 


PPC 


Pre-emptive Priority Call 


PSTN 


Public Switched Telephone Network 


PTN 


Private Telephonic Network 


PVC 


Permanent Virtual Circuit 


QoS 


Quality of Service 


ROSE 


Remote Operating Service Element 


Rt 


TETRA R reference point 


SA 


Search Area 


SAP 


Service Access Point 


S-CLNP 


Specific Connectionless Network Protocol 


SDP 


Short Data Protocol 


SDS 


Short Data Service 


SDU 


Service Data Unit 


SIM 


Subscriber Identity Module 


SMI 


Short Management Identity 


SNA 


Short Number Addressing 


SNACP 


Sub-Network Access Protocol 


SNAF 


Sub-Network Access Functions 


SNDCP 


Sub-Network Dependant Protocol 


SNICP 


Sub-Network Independent Protocol 


SS 


Supplementary Service 


St 


TETRA S reference point 


SwMI 


TETRA Switching and Management Infrastructure 


TAC 


Type Approval Code 


TAt 


TETRA Terminal Adapting functions 


TC 


Transfer of Control 


TE 


Terminal Equipment 


TE1 


TE presenting an ISDN interface 


TE2 


TE presenting a TETRA interface 


TEl 


TETRA Equipment Identity 


TETRA 


Trans-European Trunked RAdio 


TL 


Transmission Line 


TLC1 


TETRA Link layer Control No. 1 


TMI 


TETRA Management Identity 


TN 


Transit Network 


TNP1 


TETRA Network Protocol No. 1 


TNP2 


TETRA Network Protocol No. 2 


TNP3 


TETRA Network Protocol No. 3 


TNP4 


TETRA Network Protocol No. 4 


TNSDS 


TETRA Network Short Data Service 


TPI 


Talking Party Identification 
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T T 


TETRA T reference point 


Ud 


TETRA Direct Mode air interface 


Urn 


TETRA air interface 


UPT 


Universal Personal Telecommunications 


USSI 


Un-exchanged Short Subscriber Identity 


V+D 


Voice Plus Data 


V.24T 


Physical Layer Protocol over the Rt reference point 


(V)ASSI 


Visiting Short Subscriber Alias Identity or Visitor ASSI 


(V)ATSI 


Visiting TETRA Subscriber Alias Identity or Visitor ATSI 


VC 


Virtual Call 


(V)GSSi 


Visiting Short Subscriber Group Identity or Visitor GSSI 


(V)GTSI 


Visiting TETRA Subscriber Group Identity or Visitor GTSI 



4 Circuit mode reference points 



4.1 Introduction 



This clause is based on the principle of reference configurations presented in 
CCITT Recommendation 1.41 1 [6]. 

The TETRA LMN supports various speech and data services. This clause defines the general reference 
configuration and the circuit mode reference points for TETRA MSs, LSs, and the inter system interface. 
An overview of circuit mode services and examples of protocol configurations are described in clause 8. 

In order to enable data services in the TETRA LMN there is a need to connect different Terminal 
Equipment (TE) to a Mobile Termination (MT) or a Network Termination (NT). 



4.2 Reference configuration 



A general TETRA LMN configuration may comprise MSs or LSs which are connected to a terminating 
network. The terminating network may be a TETRA network (TETRA SwMI) or an ISDN network. A 
Transit Network (TN) shall be used for communication between different terminating networks. A MS shall 
include a MT and may include a TE. A LS shall include a TE and a NT. 

A TETRA LMN can offer various telecommunication services at different Service Access Points (SAPs). 
The general TETRA LMN, and the access for teleservices and bearer services supported by a TETRA 
LMN is shown in figure 1 . 



<- 



<- 



_JETRA Teleservices. 



JTETRA Bearer Services. 



TE 



NT 
or 
MT 



TETRA 
SwMI 



Possible 
transit 
network 
TN 



Terminating 
network 
ISDN or 
TETRA SwMI 



NT 
or 
MT 



TE 



j MS or LS j j MS or LS ^ 

NOTE: The terminating network may include a TETRA LMN, either the originating one or 
another one. 

Figure 1 : Bearer services and teleservices supported by a TETRA LMN 
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4.2.1 



Configuration examples of TETRA LMNs 



General configuration examples of TETRA LMNs using one ore more TETRA SwMI are shown in figure 2. 
Figure 3 shows the direct mode connection between MSs. 
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Figure 2: TETRA LMN configuration examples using a TETRA SwMI 

The examples shown in figure 2 are not exhaustive, but only illustrate possible network configurations. 



MS 


Ud 


MS 





Figure 3: MS connected to MS via direct mode interface 
4.3 TETRA LMN access 
4.3.1 MS access 

A MS shall include a MT and may include a TE. The MS access to services supported by a TETRA LMN 
is shown in figure 4. 
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Figure 4: MS access to a TETRA LMN 
4.3.1 .1 MS functional groups 

The mobile termination functional group, MT, shall support the following general functions: 
air interface termination (Um); 
radio channel management; 
Mobility Management (MM); 
speech and data encoding/decoding; 

error protection/correction for all information (speech, signalling, user data) sent across the radio 
path; 

flow control and mapping of signalling and user data; 

rate adaption between user data and radio channel rate; 

support of TE. 

There are two types of MT defined: 

MTO shall include functions belonging to the functional group MT, with support of non-standard 
terminal interfaces that provide TE functionality; 

MT2 shall include functions belonging to the functional group MT, with a terminal interface that 
complies with a TETRA recommended interface. 

The terminal equipment functional group, TE, shall support Man Machine Interface (MMI) to. the user 
(access point AP3) and shall support a TETRA terminal interface to MT2 functional group (access point 
AP2). 

There is one type of TE defined: 

TE2 represents an asynchronous (start/stop) serial TETRA specific CCITT Recommendation V. 
series interface. 



4.3.1.2 



MS access points and reference points 



The R T reference point shall define the boundary between the TE2 and MT2 functional groups. AP2 shall 
be the access point for TETRA bearer services at this reference point. 



4.3.2 



LS access 



The LS shall comprise the functional groups NT, Terminal Adapting (TA) function and TE. The LS access 
to services supported by a TETRA LMN is shown in figure 5. 
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Figure 5: LS access to services supported by a TETRA LMN 
4.3.2.1 LS functional groups 

The Network Termination functional group, (NT), shall support the functions defined by 
CCITT Recommendation 1.411 [6]. 



There are two types of NT defined: 

NT1 shall include functions belonging to the functional group NT, with support of functions specific 
to the Transmission Line (TL) interface, and may support an interface to NT2 functional group; 

NT2 shall include functions belonging to the functional group NT, with support of more than one 
network terminations, and may support an interface to TE1 functional groups or TETRA TA 
functional groups (access point AP1). 



The Terminal Equipment functional group (TE) shall support man machine interface to the user (access 
point AP3) and may support a TETRA interface to TETRA TA functional groups (access point AP2) or 
may support an ISDN interface to NT functional groups (access point AP1). 



Page 26 

ETS 300 392-1 : February 1996 

There are two types of TE defined: 

TE1 represents an ISDN interface; 

TE2 represents an asynchronous (start/stop) serial TETRA specific CCITT V. series interface. 

The Terminal Adapting functional group (TA) supports the following general functions as defined by 
CCITT Recommendation V.110 [7]: 

asynchronous (CCITT V. series) to synchronous (ISDN) conversion; 
rate adaption; 
flow control. 

There is one type of TA defined: 

TA T represents a TETRA specific terminal adapter which shall include the functions belonging to the 
functional group TA, with support of an interface to TE2 functional group and an interface to NT2 
functional group. 



4.3.2.2 



LS access points and reference points 



The R T reference point shall define the boundary between the TE2 and TA T functional groups. AP2 shall 
be the access point for TETRA bearer services at this reference point. 

The S T reference point shall define the boundary between the TE1 or TA T and NT2 functional groups. AP1 
shall be the access point for TETRA bearer services at this reference point. 

The T T reference point shall define the boundary between NT2 and NT1 functional groups. 

4.3.3 Inter System Interface (ISI) access 

The functional groups and reference points of an ISI are shown in figure 6. 
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Figure 6: ISI reference points 



ISI functional groups 



The Call Handling (CH) functional grouping shall provide signalling and call handling functions. Signalling 
information shall be sent and received, via the Switching (SW) functional grouping, to and from call 
handling functions within the TE functional grouping, peer CH functional groupings within other SwMIs, 
and call handling functions within public ISDNs. 

The Inter-network protocol Handling (IH) functional grouping shall provide signalling and connection 
handling functions for the control, where possible, of inter-SwMI connections provided by the IVN 
functional grouping. Signalling information shall be sent and received, via the Mapping (MP) functional 
grouping, to and from call handling functions within the IVN functional grouping. 
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The SwMI system manager functions should co-ordinate IH and CH functional groupings. 

The IVN functional grouping shall support communication between SwMls. Where inter-SwMI connections 
are controllable by the SwMI, the IVN functional grouping shall include call handling functions. 

The INT functional grouping shall provide transmission functions and, if applicable, layer 1 signalling 
functions between the MP and the IVN functional groupings. In the case where the real network is an 
ISDN, the INT shall be equal to an NT1 functional grouping. 

The MP functional grouping shall provide the functions necessary for mapping of user and signalling 
information between the INT and the SW functional groupings. It shall also map signalling information for 
inter-SwMI connection control between the INT and the IH functional groupings. 

The NT1 functional grouping shall be as defined in CCITT Recommendation 1.411 [6], 

The SW functional grouping shall provide switching functions for user and signalling information. User 
information shall be switched between base termination (not shown), MP and NT1 functional groupings. 
Signalling information shall be switched between CH and base termination (not shown), between CH and 
MP, and between CH and NT1 functional groupings. 

4.3.3.2 ISI reference points 

The C T reference point shall define the boundary between the MP and the INT functional groupings. In the 
case where the intervening network is a public ISDN, the C T reference point shall coincide with the T T 
reference point. 

The Q T reference point shall define the boundary between the SW and the MP functional groupings. 

The T T reference point shall define the boundary between the SW and the NT1 functional groupings. It 
shall indicate the point of inter-working between the TETRA and public ISDN capabilities. 

4.3.3.3 The significance of the C T and Q T reference points 

The interconnection of SwMls between TETRAs shall be achieved by using services of an intervening 
network, which shall be terminated at each end by the INT functional grouping. A number of different 
scenarios can be identified for the interconnection of SwMls, depending on the intervening network and 
the bearer service which it provides, e.g. dedicated transmission system, permanent or demand bearer 
services of a public ISDN or other network. Consequently the nature of the interface at the C T reference 
point may vary. 

At the Q T reference point, however, the nature of the intervening network and bearer service should not be 
visible. Although physical interfaces should not normally exist at the Or reference point, conceptual inter- 
SwMI protocols which are independent of the interconnection scenario can be specified for the Q T 
reference point. These protocols should be visible and indirectly testable at the C T reference point. 

The MP functional grouping shall provide mapping between a scenario-independent conceptual interface 
at Q T and a scenario-dependent real interface at C T , for example: 

mapping of conceptual B and D channels at Q T onto real channels or time-slots at C T ; 

conversion between scenario-independent signalling protocols at Q T and scenario-dependent 
signalling at C T . 

4.3.4 Location of TETRA functionality 

In the MS, the TETRA functionality shall reside in the MTO terminal or in the TE2 terminal together with the 
MT2 mobile termination. 

In the LS, the TETRA functionality shall reside in the TE1 terminal or in the TE2 terminal together with the 
Terminal Adapter for TETRA (TA T ). 
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4.3.5 TETRA terminals 



The AP1 access point at S T reference point may be used by both TETRA terminal equipment, TE1 and 
TE2. TE2 shall be connected to AP1 via R T reference point on access point AP2 and terminal adapting 
function TA r . The TETRA terminals connected to AP1 access point are shown in figure 7. 
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Figure 7: TETRA terminals connected to AP1 

The Urn or Ud access point may be used by the mobile termination MTO or the terminal equipment TE2. 
TE2 shall be connected to Um or Ud via R T reference point on access point AP2 and mobile termination 
MT2. The TETRA terminals connected to Um or Ud access point are shown in figure 8. 
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Figure 8: TETRA terminals connected to Um/Ud 
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5 Packet mode reference points 

5.1 Introduction 

This clause gives the reference points for the TETRA data services, the MSs, the LSs and the NMU. 

A set of examples of overall TETRA network configurations are described, together with all possible 
arrangements of the MS and the LS. 

5.2 Physical interfaces 
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Figure 9: Physical interfaces reference model 
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The physical interfaces for TETRA packet data are shown in figure 9. In this model each box represents a 
separate item of equipment (or group of equipment). Two important boundaries are shown in this diagram: 

a) the Radio Packet Data Infrastructure (RPDI) boundary which shall correspond to the physical 
boundary of the infrastructure (e.g. the air interface); 

b) the Radio Packet Data Network (RPDN) boundary which shall correspond to the network service 
boundary. The RPDN shall include a part of every MS. 

5.3 Configurations 

Figure 10 gives the basic configurations, figure 11 gives the specific configuration and figure 12 the NMU 
configuration. The PDN is assumed to handle connection and connectionless procedures. 

5.3.1 Basic configurations 

The different cases showing basic configurations are outlined in figure 10. 
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Figure 10: Basic configurations 

a MS may be connected to another MS or to a LS through a TETRA network; 

a LS may be connected through the TETRA network to a MS or to another LS; 

a LS or MS may be connected through a TETRA network and one PDN to a 
fixed DTE; 

a MS or LS may be connected through two TETRA networks to another MS or 
LS; 

a MS or LS may be connected to a TETRA network interconnected to another 
TETRA packet via a PDN. 
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5.3.2 Specific configuration 

A character mode LS shall be connected to a PAD in the TETRA network to a MS or LS (see figure 11). 
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Figure 11: Specific configuration 



5.3.3 



NMU configuration 



The NMU configuration shall be connected to at least two TETRA networks. One or more of the 
connections may be achieved through a PDN (see figure 12). 
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Figure 12: NMU configuration 



5.4 
5.4.1 



Reference points 
MS reference points 



Figure 13 shows the alternative configurations for a MS. The reference points are shown for each 
configuration. 

These configurations show a family of different MTUs (MTUO, MTU2 etc.). Each MTU shall be a physical 
entity, that contains all of the air interface stack. The TE shall support the application, the MMI to the user 
and the interface with the MTU. The MTU shall support the functions specific to the TETRA air interface 
and the interface to the TE. 

R0 shall be a reference point within the MTU. It shall correspond to the top of the MRS not including the 
routing. R0 shall be the network service boundary. This reference point shall exist in all MTUs. 

R1 shall be a reference point between packet mode TE (TE2) and the MTU (MTU2). There may be 
several alternative interface protocols at R1 , including existing packet mode standards. 



R2 shall be the reference point at the TETRA air interface. 



R4 shall be the reference point for a character mode TE (TE3) connected to a PAD. There may be several 
alternative interface protocols at R4, including existing PDN standards. 

The PAD may be a separate unit or may be physically integrated in the MTU, this integrated PAD is 
labelled MTU3. 
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Figure 13: MS reference points 



5.4.2 



LS reference points 



Figure 14 shows the LS reference point R1 for packet mode LSs. For character mode terminal the 
connection can be made via a PAD through the R4 reference point. For LSs both the R1 and the R4 
interfaces should use existing PDN standards. 
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Figure 14: LS reference points 
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5.4.3 NMU reference point 

Figure 15 shows R5 which shall be the reference point between the NMU and the TETRA network. 




5.4.4 



Figure 15: NMU reference point 
TETRA to TETRA reference point 



Figure 16 shows R6 which shall be the reference point between one TETRA network and another TETRA 
network. 
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Figure 16: TETRA to TETRA reference point 

Figure 17 shows the more general case of reference point R6 t where the two TETRA networks are 
connected via a transparent transit network. R6 shall be the reference point between one TETRA network 
and the transparent transit network. 
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Figure 17: TETRA to TETRA reference point 
TETRA to non-TETRA reference point 



Figure 18 shows R7 which shall be the reference point between one TETRA network and a non-TETRA 
packet data network. 




Figure 18: TETRA to non-TETRA reference point 
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5.5 Protocol stacks 

5.5.1 Protocol stacks at R1 reference point 

Figure 19 refers. The protocol stacks at the R1 interface shall be for operation over a line connection. 
These may be used for the interface between a TE2 and a MTU2, or to interface a packet mode LS. 
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Figure 19: Protocol stacks at the R1 reference point 
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5.5.2 Protocol stacks at R2 reference point 

Figure 20 refers. These protocol stacks shall be the TETRA air interface stack. 
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Figure 20: Protocol stacks at R2 reference point 
5.5.3 Protocol stacks at R4 reference point 

Figure 21 refers. These protocol stacks shall support character mode operation. 
This is the character mode equivalent of the packet mode R1 reference. 
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Figure 21 : Protocol stacks at R4 reference point 
Protocol stacks at R6 reference point 
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Figure 22 refers. Each of the TETRA networks shall operate directly to the other TETRA network, 
independently whether there is a transparent transit network between them or not at the R6 reference 
point. 
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Figure 22: Protocol stacks at R6 reference point 
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6 Protocol architecture for V+D 

6.1 Introduction 

The purpose of this protocol architecture is to be a model where the different functions and processes are 
identified in the different layers in the mobile/base and LS protocol stacks. It gives an ISI overview as well. 

NOTE: The protocol stacks are used to define the functionality of the TETRA protocols for 
interfaces. The protocol stacks in this clause and in all other related clauses are 
normative when used to describe functionality of interfaces, but these stacks and sub- 
division of protocol layers does not imply or restrict any implementation. 

6.2 Mobile/base protocol architecture 

6.2.1 Overview 

The base of the protocol stack shall rest on the physical layer. 

The data link layer shall be composed of two sub-layer entities as described hereafter (MAC and LLC). 

An explicit Medium Access Control (MAC) sub-layer shall be introduced to handle the problem of sharing 
the medium by a number of users. At the MAC, the protocol stack shall be divided into two parts, the user 
plane (U-plane) for transporting information without addressing capability and the control plane (C-plane) 
for signalling with addressing capability. 

A Logical Link Control Entity (LLCE) shall reside above the MAC and shall be responsible for controlling 
the logical link between a MS and a BS over a single radio hop. In cases where the protection offered by 
the MAC (FEC + CRC) is sufficient and acknowledged service is not requested, the functionality in the 
LLCE is small. 

An explicit Mobile/Base Control Entity (MLE/BLE) sub-layer shall reside above the LLCE for handling 
establishment and maintaining the connection to the BS. The MLE/BLE shall also act as a convergence, 
so the same layer 3 entities can be used on top of different layer 2 entities. 

At the top of the protocol stack (layer 3, see figure 23), several entities may be present: Mobility 
Management (MM), Circuit Mode Control Entity (CMCE), Connection Oriented Network Protocol (CONP) 
and Specific Connectionless Network Protocol (S-CLNP). 

A Lower Layer Management Entity (LLME) shall contain the databases. The required layer management 
functionalities shall be contained in the layers. The interactions between non adjacent layers shall go 
through specific SAPs (see the model in subclause 6.3.1). 

Figure 23 shows the protocol layering for the MS and the BS. The following subclauses describe the major 
functions handled by each layer. 

6.2.2 Air interface layer 1 

The air interface layer 1 shall be the physical interface. It shall deal with the physical burst, composed of 
bits and symbols (= association of 2 bits), which is to be sent and/or received. 

The air interface layer 1 shall contain the following functions: 

radio oriented: 

1) modulation/demodulation as defined in ETS 300 392-2 [1 7], clause 5. 

2) transmitter/receiver switching as defined in ETS 300 392-2 [17], clause 6. 

3) RF characteristics: as defined in ETS 300 392-2 [1 7], clause 1 0: 

frequency (or channel) setting; 
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outputs Radio-Signal-Strength-Indicator (RSSI). 

4) fine adjustments of radio parameters: 

frequency correction: the synchronisation on to the BS frequency using a specific 
frequency correction sequence shall be located inside the Synchronisation burst as 
defined in ETS 300 392-2 [17], clauses 7 and 9; 

power control: MS power level adjustment according to BS broadcast parameters and 
signal strength measurements in the MS as described in ETS 300 392-2 [17], 
clause 23; 

broadcast parameters related to power control shall be part of the MAC block and 
hence shall be decoded at the MAC level (see ETS 300 392-2 [17], clause 21). 

bits and symbol oriented: 

symbol synchronisation: a specific training sequence, located inside the burst, shall precisely 
determine the occurrence of the symbols. For first time synchronisation acquisition, an 
extended training sequence (longer than the normal one) shall be available on the 
synchronisation burst (see ETS 300 392-2 [17], clause 7). The physical layer shall then be 
able to determine the burst boundaries (i.e. the beginning and the end). 

burst building: 

1) receiving/submitting data from and to the MAC sub-layer: because the physical layer shall be 
able to determine the starting and ending points of the burst, at the emission, it shall map the 
MAC block onto the physical burst and shall add its specific information (layer 1 only) at the 
correct place. At the reception, it shall extract its specific information (layer 1 only) from the 
burst and shall rebuild MAC block(s), see ETS 300 392-2 [17], clause 9. The MAC block(s) 
shall then be passed to the MAC; 

2) slot flag coding/de-coding using two distinct training sequences, see ETS 300 392-2 [17], 
clause 9. The use of the slot flag is described in ETS 300 392-2 [17], clause 19; 

3) scrambling/de-scrambling: both BS and MS shall scramble frames prior to sending them. 
Scrambling shall be done according to the base station address, known as colour code. So, 
the frame shall be decoded correctly only by the receiving station having that colour code 
(de-scrambling). Refer to ETS 300 392-2 [17], clause 8. 

6.2.3 Air interface layer 2 

The air interface layer 2 shall handle logical connections and shall hide the physical medium from the 
upper layers. An overview can be found in ETS 300 392-2 [17], clause 19. 

6.2.3.1 Medium Access Control (MAC) 

The MAC shall handle radio channel access and radio resource management. For a detailed description 
of the services and protocol, see ETS 300 392-2 [17], clauses 20 and 23. 

The main functions shall be as follows: 

channel coding: 

a) interleaving, de-interleaving and re-ordering the protected bits over one block or two blocks 
allow spreading the errors instead of having them grouped as it is usually the case in radio 
systems (see ETS 300 392-2 [1 7], clause 8); 
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b) channel coding see ETS 300 392-2 [17], clause 8: 

1) in order to protect bits transmitted on the radio path, Forward Error Correction (FEC) 
using convolutional coding shall add some redundancy (e.g. 2/3 coding, which 
encodes 2 bits of information into 3 transmitted bits) so that errors may be corrected 
afterwards; 

2) a Cyclic Redundancy Check (CRC) shall be performed on the incoming block of 
information so that errors may be detected up to a certain amount, depending on the 
size of the CRC. 16 bits CRC will ensure a protection against undetected errors. The 
receiving MS shall calculate the CRC on the received bit stream using the same 
algorithm and shall compare the results. The actions taken in case of error are 
described in ETS 300 392-2 [17], clause 23. 

radio channel access control: 

the performed functions shall be as follows: 

a) frame synchronisation: 

keeps track of the frame number within a multiframe; 

b) random access procedure: 

contention control on a particular physical channel; 
flow control of up-link random access. 

c) fragmentation/re-assbciation: 

this shall split the content of one single PDU into several SDUs. On the other 
side, parts shall be re-associated together in order to re-constitute the original 
PDU; 

d) multiplexing/de-multiplexing of the logical channels: in order to create all layer 2 parts 
of the burst (see ETS 300 392-2 [17], clause 9 and clause 23); 

e) multiframe building and synchronisation: this is where the frames shall be assembled 
to form a multiframe or a hyper-frame which content may vary according to a cyclic 
law. They shall be numbered explicitly i.e. on the downlink, a synchronisation block 
shall contain information about time slot, frame and multiframe number, colour code 
information of the BS, and network code (see ETS 300 392-2 [17], clause 9). 

radio resource management: 

this part shall be unique to one mobile or base station. It shall enable powerful control of the 
radio resources to be available at any time without explicit involvement of layer 3. The 
following functions shall be provided: 

a) Bit Error Ratio (BER) and BLock Error Rate (BLER) measurements: independently or 
under control of other layers; 

b) path loss calculation: monitoring of the serving cell and monitoring and scanning of 
adjacent cells (see ETS 300 392-2 [17], clause 23); 

c) address management for individual, group or broadcast calls. Two MAC addresses 
can be used: 

a copy of the ISSI, ASSI, USSI or GSSI (passed as a parameter from layer 3); 
and 

an event label (see clause 7 and ETS 300 392-2 [17], clause 19); 
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d) power control management (execution is in the physical layer); 

e) radio path establishment: frequency, time slot and colour code selection according to 
the MLE (layer 3) indications. ETS 300 392-2 [17], clauses 1 1 , 14, and 23, shall apply; 

f) radio resource allocation shall be performed. Channel allocation (frequency and time 
slot) may depend on the system mode of operation, i.e. message trunking, quasi- 
transmission trunking, transmission trunking, discontinuous transmission. This 
functionality enables efficient and fast channel access and drop time; 

g) control information and speech frames should be buffered until transmitted; 

h) circuit mode applications (e.g. CODEC and circuit mode data) interface with MAC layer 
as represented in figure 23 (U-Plane) and described in more detail in ETS 300 392-2 
[17], clause 20. 

6.2.3.2 Logical Link Control (LLC) 

The LLC shall handle the point-to-point logical links between the MS and the BS. It shall be appropriate 
only for C-plane operation. Two different services may be provided: 

a basic link shall be supported, which does not need any establishment phase; and 

on request, an advanced link may be supported for better grade of service (see ETS 300 392-2 
[17], clauses 20 and 22 for details). 

The functions shall be as follows: 

exchanging control and/or user data with the Mobile/Base Link control Entity sub-layer (MLE); 

logical link handling (basic link and advanced link); 

scheduling data transmission; 

re-transmissions (single in basic link and selective in advanced link); 
segmentation/re-assembly (advanced link only); 
error measurement (extended error detection in advanced link); 
flow control (advanced link only); 

acknowledgement of received data (basic link and advanced link); 

logical channel allocation negotiation with the MAC (advanced link only). 
6.2.4 Air interface layer 3 
The air interface layer 3 shall handle network procedures. 
6.2.4.1 Mobile/Base Link control Entity (MLE/BLE) 

This sub-layer, which is applicable to the C-plane, shall be a platform for the services offered in the layer 
(see ETS 300 392-2 [17], clause 17 and clause 18 for further details). 

The functions shall be as follows: 

protocol discrimination; 

management of the mobile-base association (connection); 
identity management; 
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quality of service selection; 

mobility within a Registered Area (RA). 

Another function of the MLE shall be to handle common broadcast information. Through the C-SAP (refer 
to subclause 10.4), it may have interactions with all layers. 

The functions shall be as follows: 

broadcast and receive network information; 

pass channel information to the layers below via C-SAP (refer to subclause 10.4). 
6.2.4.2 Sub-Network Access Functions (SNAF) 

This layer shall have SAPs for circuit-switched voice and data call control services, connection oriented 
and connectionless packet services, Short Data Service (SDS), Mobility Management (MM) and 
supplementary services. The functions for these different services shall be as listed below. 

6.2.4.2.1 Mobility Management (MM) 

MM shall handle functions that are necessary because of MS mobility (see ETS 300 392-2 [17], 
clauses 15 and 16 for further details). 

The functions shall be as follows: 

selection of LA; 

registration; 

authentication; 

user attachment; 

network selection. 

6.2.4.2.2 Circuit Mode Control Entity (CMCE) 

The CMCE shall be subdivided into three sub-entities, i.e. SDS, Call Control (CC) and supplementary 
services control (see ETS 300 392-2 [17], clauses 11 , 12, 13, and 14 for further details). 

SDS: 

SDS shall handle connectionless data messages with the following capabilities: 

minimise the number of transmissions required to send the short data as signalling 
message; 

source and destination address associated with the short data; 

sen/ice available independent of whether a circuit switched call is in progress; 

point-to-point and point-to-multipoint; 

efficient coding of user messages (pre-defined and user-defined). 
Refer to ETS 300 392-2 [17], clause 13 for further details. 
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CC: 

the call control shall handle circuit mode calls with the following functions: 

establishing, maintaining and clearing basic service calls; 

addressing (destination); 

call identity. 

supplementary services control: 

supplementary services control shall handle the processes associated with supplementary 
services (see ETS 300 392-2 [17], clause 12 for further details). 

The functions shall be as follows: 

provision and withdrawal; 

activation/deactivation; 

definition; * 
registration; 

invocation and operation; 

interrogation; 

cancellation. 

6.2.4.2.3 Packet data handling 

The packet handling entity shall handle the packet data services offered by TETRA. 

6.2.4.2.4 Connection Oriented Network Protocol (CONP) 

The CONP shall handle the standard ISO 8208 [11] (X.25 PLP) functions with the modifications described 
in ETS 300 392-2 [17], clauses 24 and 25. 

The functions shall be as follows: 

CONP (X.25 PLP); 

network connection control; 

data transfer; 

queue management. 

6.2.4.2.5 TETRA Specific-Connection Less Network Protocol (S-CLNP) 

The TETRA S-CLNP shall handle the specific connectionless network protocol (see ETS 300 392-2 [17], 
clauses 26 and 27 for further details). 

The functions shall be as follows: 

point-to-point data transfer; 

point-to-multipoint data transfer. 
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Figure 23: Mobile/base station protocol stack 

| Service Access Point (SAP); 

AI-1 Air Interface layer 1 ; 

AI-2 Air Interface layer 2; 

AI-3 Air Interface layer 3; 

C-plane Control-plane, control information available; 

CLNS ISO Connectionless Network Service; 

CMCE Circuit Mode Control Entity; 

CONP Connection Oriented Network Protocol; 

CONS Connection Oriented Network Service; 

LLC Logical Link Control; 

MM Mobility Management; 

S-CLNP TETRA Connectionless Network Protocol; 

S-CLNS TETRA Connectionless Network Service; 

SNAF Sub-Network Access Functions; 

U-plane User-plane, control information not available. 

Lower Layer Management Entity (LLME) and other layers interaction 



6.3.1 



General description 



The LLME is a vertical entity through which layers exchange information. It enables access to measured 
values, status, and to general information. Its interaction with the layers may be represented as shown in 
figure 24. 
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Figure 24: TETRA protocol stack with LLME interaction 

Only testable parameters are standardised. Each layer shall have its own set of functions and measured 
values. The functions related to the management of a particular layer shall be described inside that layer. 
Although these parameters are exchanged with the LLME (stored and retrieved) using a set of messages 
(PDUs), they are standardised and described in appropriate subclauses of this ETS. 

7 Addressing and identities 
7.1 Introduction 

This clause defines the TETRA addresses and identities that shall be used by all TETRA equipment. 

The identities are organised into the following groups corresponding to the different functions of the 
addresses and identities: 

a) TETRA Subscriber Identities (TSI); 

b) Short Subscriber Identities (SSI); 

c) TETRA Management Identities (TMI); 

d) Network Layer SAP addresses (NSAP); 

e) TETRA Equipment Identities (TEI); 

f) Mobile Network Identity (MNI). 

TETRA addresses and identities are designed to support the following objectives: 

a) to allow a large number of networks (and network operators) to co-exist, and for each network to 
support a large number of subscribers; 



b) to be able to uniquely identify any subscriber in any network; 
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c) to allow the use of shortened identities for intra-TETRA calls to reduce the signalling information in 
the set-up messages; 

d) to support efficient roaming and migration of subscribers. 

The main TETRA identities are the subscriber identities. A key difference between TETRA and public 
mobile networks is the existence of group identities. As far as possible, group identities within TETRA 
shall be treated identically to individual identities, i.e. group and individual identities shall have the same 
structure and shall be allocated from the same TETRA identities space. 

Nonetheless, the individual subscriber identities shall have a special role to provide a unique identification 
of terminal users because an individual subscriber identity can only refer to one mobile (or fixed) 
termination. By contrast, a group subscriber identity can refer to several mobile (or fixed) terminations. 

The subscriber identities may be transferable, and may be removed from the equipment by the user. An 
additional non-transferable management identity shall be defined to allow a termination to be addressed 
independently from the subscribers. 

NOTE: Fleet addressing is outside the scope of this ETS. 

The different addressing domains relevant to TETRA are shown in figure 25. The TETRA domain is 
shown as intersecting three other domains (PSTN, ISDN and PDN). This indicates that a given individual 
TETRA subscriber address may be associated with one address in each of these public domains. 




Figure 25: Addressing domains within TETRA 

Within the TETRA domain, the TETRA identities can have different roles. The relationship between the 
different TETRA identities and the other addresses is shown in figure 26. 
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Figure 26: Relationship between TETRA addresses 

The use of addresses in TETRA set-up messages and other messages are described in subclause 7.8. 
7.2 Subscriber identities 

7.2.1 General 

Subscriber identities (TSI or SSI) shall exist in two sizes: 

TETRA Subscriber Identity (TSI), 48 bits long; 

Short Subscriber Identity (SSI), 24 bits long. 
The SSI shall be a truncation of the TSI. 

Each TSI shall be unique across the complete TETRA domain, i.e. all TETRA networks, but each SSI 
shall only be unique in one TETRA sub-domain, i.e. one TETRA network. 

NOTE: These subscriber identities do not necessarily correspond to "chargeable subscribers". 
The definition of "chargeable subscribers" is outside the scope of this ETS. 

7.2.2 TSI 

Each MS or LS shall contain at least one family of TSIs. Each family shall contain one Individual TETRA 
Subscriber Identity (ITSI) and may also have one ATSI and several Group TETRA Subscriber Identities 
(GTSIs): 

One TSI family: 

1 x ITSI; 
IxATSI; 
N x GTSI. 
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This TSI family shall be valid for a home TETRA network. Likewise, one or several visitors TSI families 
may also coexist with the home TSI family but shall have a slightly different composition: 

they shall not contain a visiting equivalent to the individual identities, i.e. no (V)ITSI. 

The binding between home and visitors TSI families is outside the scope of this ETS. The lifetime of these 
addresses is an operator option, but the visitors TSI family shall be deleted at de-registration. 

In visited networks, an alias address shall be provided by the SwMI. Other MSs shall continue to use the 
(home) individual address to access MS in visited networks. 

The following will only consider the requirements for a single family. A single termination may contain 
more than one TSI family, and in this case each family shall meet these requirements independently of the 
other families. 

TSIs shall be allocated by the network operators. A valid TSI shall refer to a TSI that has been allocated 
by the network where it is being used. A MS or LS shall possess at least one valid ITSI before it can be 
used. Special procedures are defined to allow a migrating subscriber to attach to a visited network and to 
"exchange" an existing ITSI for a valid TSI for that visited network. This exchanged TSI shall be known as 
a visitors ATSI or (V)ATSI, and this new (V)ATSI should be allocated when the migrating visitor first 
contacts the visited network. 

A valid ITSI shall be required in order to support the air interface addressing procedures (refer to 
subclauses 7.2.6 and 7.8). 

NOTE 1 : Subject to inter-operator agreements, the functionality of a (V)ATSI may be identical to 
the ITSI (i.e. a migrating subscriber may be offered an equivalent service to the non- 
migrating subscriber). 

To support secure network operations, an ATSI may be allocated in addition to the ITSI. There shall only 
be one ATSI per ITSI and the ITSI-ATSI pairing shall only be known to the network operator. The ATSI 
cannot be derived from a knowledge of the ITSI, and a given subscriber shall only be known to other 
subscribers by his ITSI. 

Because the ATSI shall not be available to other users, the network operator may change the value of the 
ATSI at frequent intervals without notifying any of the other users. Infrastructure routing tables are 
assumed to operate using the public ITSI. 

If a valid ATSI is available for a given network, this shall be used in place of the ITSI as described in 
subclauses 7.2.6 and 7.8. 

The ATSI does not replace the ITSI. The ITSI shall remain available (by definition) and can still be used if 
required. 

To support group addressing, one (or more) GTSI shall be allocated in addition to the ITSI. There may be 
several GTSI per ITSI and the same GTSI may be associated to several ITSIs. The binding between the 
GTSI and the ITSI is outside the scope of this ETS, and a given group subscriber shall only be known to 
other subscribers by his GTSI. 

NOTE 2: There is no group equivalent of the ATSI. 

The ATSI and the GTSIs may be either pre-allocated (like ITSIs) or may be allocated dynamically by the 
network using standard TETRA procedures as part of normal operation. (V)ASSIs and (V)GSSIs may also 
be exchanged by the visited network (like in the home network). 

NOTE 3: No standard procedures are defined for the dynamic allocation of ITSIs. 

The method(s) of TSI installation are described in subclause 7.2.8. 
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7.2.3 SSI 

The SSI is the network specific part of the TSI. SSIs shall be unique within a given TETRA sub-domain 
(i.e. a given network). The same SSI may be used in many TETRA sub-domains. 

An Individual Short Subscriber Identity (ISSI) shall be formed from an ITSI by removing the Mobile Country 
Code (MCC) and the Mobile Network Code (MNC). Likewise, a GTSI shall be truncated to a Group Short 
Subscriber Identity (GSSI). 

Valid values for an SSI shall correspond to the valid types of ITSI as follows: 
ISSI = SSI from ITS!; 

ASSI = SSI from ATSI (see subclause 7.2.2 notes 1 and 2); 
GSSI = SSI from GTSI; 

USSI = SSI from a foreign ITSI (see subclause 7.2.2 note 2). 

If an ASSI is available, this shall be used in place of the ISSI. (For more details see subclauses 7.2.6 and 
7.8). The ASSI does not replace the ISSI. The ISSI shall remain available (by definition) and may still be 
used by the infrastructure if required. The ISSI may also be used by the MS if for example the ASSI 
assignment expires. 

NOTE: There is no group equivalent of the ASSI. 

Most MS operations should use the valid home (or visitor) values of SSI. However, an Un-exchanged SSI 
(USSI) shall also be defined to support migration. This non-valid SSI, based on the home ISSI, shall be 
used instead. The USSI shall be formed by using a "foreign" ISSI as defined in subclause 7.7. Additional 
rules for the use of SSIs are defined in subclause 7.7. 

The USSI enables a MS to register with the visited network. As part of this registration, the USSI shall 
normally be exchanged for a valid ASSI. Group SSI may also be exchanged at the same time. A special 
flag in the messages shall indicate when an USSI is used. 

7.2.4 Composition of subscriber identities 
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Figure 27: Contents of TSI 

TSI identities shall have a fixed length structure that is based on the identity structures defined in 
CCITT Recommendation E.212 [3]. 

The partitioning of the address space between ITSIs, ATSIs and GTSIs shall only be known inside the 
relevant sub-domain. Outside of this sub-domain ITSI, ATSI and GTSI cannot be distinguished. 

The ASSI shall be unique for the whole sub-domain (the whole network). The relationship between a given 
ASSI and the corresponding ITSI is not defined in this ETS. 

7.2.5 Allocation principles for subscriber identities 

MCC shall use 10 bits to encode the 3 decimal digit value of the country code as defined in annex D of 
CCITT Recommendation X.121 [8]. 
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EXAMPLE: France has the country code 208 Decimal. 

This is coded as 00 1101 0000 Binary ( 0D0 hexadecimal). 

The undefined binary codes (decimal values 1000 to 1023) are reserved and shall not be used. 

MNC shall be allocated possibly by the National Administration for each country. A unique MNC shall be 
allocated to each operator using binary code on 14 bits. 

The SSIs (ISSI, ASSI or GSSI) shall be allocated by the network operator. 

NOTE: The ISSI assignment is expected to be a long term assignment, but the ASSI and 
GSSI assignments are expected to be more dynamic. It is the responsibility of the 
network operator to ensure that all of these identities are allocated uniquely at all 
times. 

7.2.6 Use of subscriber identities 

Subscriber identities shall be used for two distinct roies: 

a) as a lower layer address (MAC address) for the air interface as described in subclause 7.7 (SSI); 

b) as a network routing address (TSI). 

The MM, the CMCE and the S-CLNP shall use subscriber identities as network routing addresses. This 
may include both source and destination addresses. 

The CMCE or S-CLNP destination address shall be either: 

a) an ISSI or GSSI for intra-TETRA calls; if available, an ASSI shall be used by the SwMI. i.e. 
destination in the same TETRA network as the source; or 

b) an ITSI or GTSI for inter-TETRA calls; if available, an ATSI shall be used by the SwMI. i.e. 
destination in a different TETRA network to the source. 

NOTE: The use of a SSI as the destination address is provided to allow the use of a short 
set-up message for intra-TETRA calls. 

The source address shall be either: 

a) an ISSI or ASSI for intra-TETRA calls, i.e. source in its home TETRA network; or 

b) an ITSI (downlink and ISI) or (V)ASSI (uplink) for inter-TETRA calls, i.e. source not in its home 
TETRA. 

If an ASSI is available, this shall be used in preference to the ISSI for the source address by a MS and for 
the destination address by the SwMI when appropriate. 

7.2.7 NSAP addresses 

In some cases NSAP addresses shall be used as the source and destination addresses instead of using 
subscriber addresses. This alternative shall apply to the following cases: 

a) in all CONP packets. These shall contain both a source and destination address based on 
CCITT Recommendation X.1 21 [8]; 

b) by the CMCE for external calls; 

c) by an external protocol, such as ISO CLNP or Internet IP. 

NOTE: These external protocols are assumed to be converged onto S-CLNP. 

In the case of the CONP protocol, the NSAP address shall be allocated by the TETRA network operator, 
and it shall be bound to a valid ITSI as defined in subclause 7.4. Binding to a group TSI is not supported. 
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The SSI shall continue to be used as the lower layer address, but any combination of ITSI and NSAP may 
be used as a network routing address within the infrastructure. 

In all other cases (where the NSAP address is not allocated by the TETRA network operator) the binding 
of NSAP addresses to ITSIs are not defined in this ETS. 

7.2.8 Installation of TSIs 

TSIs may be installed by several alternative mechanisms: 
ITSIs or GTSI may be installed as follows: 

a) by the dealer (i.e. not usually changed by the user); 

b) by inserting a "smart card"; 

c) by the user entering a login code via a local MS/LS application. 

NOTE 1 : These mechanisms are only provided as examples. No methods of installation are 
defined by this ETS. 

In addition GTSIs (but not ITSIs) may also be allocated (downloaded) over the air interface to allow 
dynamic groups and to enable the user to automatically "collect" his GTSIs by registering the ITSI (e.g. 
when replacing faulty equipment or when M logging-in" to a new MS). 

Visitors to a TETRA network shall initially register using their permanent (home) (H)ITSI according to the 
procedure described in ETS 300 392-2 [17], clause 16. If this migration is accepted, the network shall 
allocate a temporary visitors (V)ATSI (and possibly visitors (V)GTSIs) using spare TSI addresses 
(allocated from the sub-domain of the visited network). The visitor shall then use the (V)ASSI as his 
source address for all subsequent messages in this visited network. 

NOTE 2: Allocations of (V)ASSIs to visitors are temporary, and it is assumed that the network 
will subsequently wish to re-allocate them to another migrating subscriber. The 
network operator should create suitable mechanisms to avoid duplicate allocations. 

7.3 TETRA Management Identity (TMI) 

7.3.1 General 

The TMI is defined as a non-transferable network (layer 3) identity. The TMI shall be allocated to a 
termination before it can be used, and it cannot be exchanged dynamically or transferred between 
terminations by the user. 

The TMI shall be allocated by the network operator and should be installed in the termination prior to 
delivery to the customer. 

The TMI shall only be used as an address by the internal network management functions using a specific 
set of management messages. These management messages, and therefore the TMI address space, 
should be inaccessible to normal network users. 

7.3.2 Composition of management identities 

The composition of the TMI shall be identical to the TSI as described in subclause 7.2.4. The MCC and 
MNC fields shall have the same values as the corresponding TSI. However, the TMI identities should be 
allocated from a separate address space, i.e. the management address space. TMI shall be composed of 
Mobile Network Identity (MNI) (i.e. MNI = MCC + MNC) and Short Management Identity (SMI), (see also 
subclause 7.6). 

NOTE: The SMI part of a TMI may be numerically equal to the SSI part of a TSI, but the TMI 
and TSI identities remain distinct because they relate to different families of messages. 
The SMI is also a valid layer 2 address. 
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Figure 28: Contents of TMI 

A visitors TMI shall not be allocated to a migrating station. The TMI shall only be allocated by the home 
network. 

7.3.3 Use of management identities 

The TMI shall only be used to support management functions such as defined in the MLE (see 
ETS 300 392-2 [17], clause 18). The TMI shall not be used for messages to or from any other than the 
network management entities. These management functions may include both standardised and non- 
standardised functions. 

NOTE: Secure networks may restrict the use of the TMI, e.g. they may allow no TMI functions 
at all. 

7.4 Network layer SAP (NSAP) addresses 

7.4.1 General 

NSAP addresses are an additional method of addressing that may be used to provide direct compatibility 
with external (non-TETRA) networks. The use of NSAP addresses is an operator option for the V+D 
systems. 

The mapping between NSAP addresses and a TETRA terminal is described as "binding". This binding 
may take place when an NSAP address is allocated to a particular TETRA mobile (MT) or to an 
independent source of identity such as a Subscriber Identity Module (SIM) card. This binding is described 
as static. Alternatively, the association may be flexible so that the association may be changed by either 
the network operator or the user. This is dynamic binding. 

7.4.2 Static binding 

Procedures for static binding are the responsibility of the administration of any particular network and are 
outside the scope of this ETS. 

7.4.3 Dynamic binding 

7.4.3.1 General 

The TETRA network shall treat NSAP addresses as "user numbers" that are associated with the TE. A 
"binding" process is defined whereby a NSAP addresses becomes temporarily associated with one MT or 
one NT. 

All NSAP addresses shall conform to the one of the existing international standards, e.g. 
CCITT Recommendations E.163 [1], E.164 [2] or X.121 [8] or to a standard private numbering plan. None 
of these standards provides support for group addressing and therefore a NSAP address shall not be 
bound to a GTSI. 

NSAP addresses shall be used to address external users (destination NSAP) and for external users to 
address TETRA users. 

NOTE: It is assumed that GTSI binding to an NSAP address is possible at a gateway. 

7.4.3.2 Structure and contents of NSAP addresses 

The structure and contents of the NSAP is defined by the appropriate numbering plan: 
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NSAP = CCITT Recommendation E.163 [1]; or 

CCITT Recommendation E.164 [2]; or 
CCITT Recommendation X. 121 [8]. 

7.4.3.3 Use of NSAP addresses 

Each network operator may allocate NSAP addresses in addition to TSIs. 

Standard NSAP addresses shall be used for the CONP to support direct inter-working to existing fixed 
networks, (see subclause 7.2.7). 

NSAP addresses may also be used by the CMCE for routing calls from external users (non-TETRA users) 
according to the principles outlined in CCITT Recommendation E.213 [4]. 

NSAP addresses may also be used as part of external protocols. 

7.4.3.4 Binding of NSAP addresses 

In order to receive calls, a NSAP address shall be temporarily bound (attached) to one ITSL This binding 
may be changed by the user and/or by the network manager at any time. Ideally a user should be able to 
bind an NSAP address to a new ITSI by simply unplugging the TE and plugging it into the new MT (or NT). 

Alternatively, a network operator can create the binding over the air interface. 

NSAP address binding requires a set of binding protocols. TE binding shall be reported to the MTU with a 
TE protocol. MTU binding shall be reported to the infrastructure using the MM registration procedures, and 
every change of binding shall be reported with a new registration. LS address binding may follow the same 
rules. 

NOTE: User changes are assumed to correspond to the attachment of new TE. 
7.5 TETRA Equipment Identity (TEI) 

7.5.1 General 

The TEI uniquely identifies one piece of TETRA equipment, either one MT or one NT. 

The TEI shall be allocated by the equipment manufacturer. One manufacturer may supply several 
networks, and therefore the TEI shall not be specific to one network. 

7.5.2 Contents of TEI 
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Figure 29: Contents of TEI 

TEI digits shall only use the decimal digits: 0-9 inclusive. 
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7.5.3 Allocation principles for TEI 

Type Approval Code (TAC) shall be allocated by a central body. 

Final Assembly Code (FAC) shall identify the manufacturer and place of final assembly. These shall be 
also allocated by a central body. 

Electronic Serial Number (ESN) shall be an individual serial number that uniquely identifies each 
equipment within each TAC+FAC. ESN shall be allocated by manufacturers in sequential order. 

7.5.4 Use of TEI 

TEI shall be used to support TETRA security functions e.g. MS enable and disable as described in 
ETR 086 [16]. 

7.6 Mobile Network Identity (MNI) 
7.6.1 Contents of MNI 
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Figure 30: Contents of MNI 

The MCC and MNC are the same as the MCC and MNC fields used in the ITSI and TMI identities. The 
coding for these fields is defined in subclause 7.2.5. 

NOTE: Additional operator information may be included as part of the system broadcast 
information. 

7.7 Layer 2 addresses and labels 

7.7.1 Overview 

The following subclauses shall only apply to MTs. Layer 2 addressing for LSs is outside the scope of this 
ETS. 

In the lower layers of the air interface, the primary layer 2 addresses shall be based on the SSIs as 
defined in subclause 7.2.3. This use of subscriber identities requires a subscriber identity to be allocated 
to all terminations before they can access the network. 

The following subclauses describe additional layer 2 addressing functions. These additional functions are 
divided as follows: 

event labelling, using information bits that are part of the message content; 
scrambling labelling, using a scrambling technique, not part of the message content. 

7.7.2 Event labelling 

As an example, an event label may be used to identify all of the separate transmission events that belong 
to one or more transactions. These labels shall be cell specific to a particular channel (i.e. they may not be 
unique outside that cell) and they may be used to label both traffic events and control events. 

The shortest duration of one label shall be one transaction, but the same label may be used for more than 
one transaction. 
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NOTE: An event label may be unique for a complete cell, or for part of a cell: e.g. specific to 
one carrier, or to one slot on one carrier. 

In addition to providing a cell specific reference for each event, the event labels may also be used to 
define control groups by each BS. These ad-hoc groups may be used by each BS to control e.g. priorities 
(random access) and battery saving. 

7.7.3 Scrambling labelling 

The scrambling labelling functions are defined to ensure that transmissions on a given channel are only 
received by the intended endpoints. Scrambling labelling shall contain an infrastructure endpoint 
identification. This scrambling label shall consist of the MNI from layer 3 and a cell number (colour code) 
from layer 2. This BS identity shall be geographically unique. 

NOTE: The cell number can only provide protection against co-channel interference when all 
co-channel sites belong to the same operator. The operator should allocate a different 
cell number for all co-channel cells (for reasonable cluster sizes). However, the co- 
channel sites may belong to different operators, and this level of co-operation cannot 
be assumed. Therefore the MNI is also required. 

7.7.4 Use and implementation of layer 2 addresses 

7.7.4.1 General requirement 

A scrambling label shall be used as part of every transmission event for both signalling and traffic, except 
for the downlink synchronisation channel where the unscrambled scrambling label shall be located. In 
addition to this, event labelling may also appear. However, there are some exceptions to this general 
requirement as described in the following subclauses. 

The scrambling label shall be used for all downlink transmissions except for the V+D downlink 
synchronisation channel where the unscrambled scrambling label shall be located. 

The scrambling label shall be used for all uplink station transmissions. Un-reserved uplink transmissions 
shall also include an individual subscriber identity (either the ISSI, the ASSI or the USSI). 

7.7.4.2 Implementation of event labels 

Event labelling identities shall be either: 

a) a network/layer 3 call reference (for circuit mode call traffic channels) called Call ID, 14 bits (see 
ETS 300-392-2, clause 14); 

b) an SMI, ISSI, USSI, GSSI or ASSI (i.e. the SSI may serve a dual role of MS identification as layer 2 
and layer 3 address, 24 bits); 

c) an event label, which is a local layer 2 temporary address that replaces an SMI, ISSI, GSSI or ASSI. 
It is specific to one channel and is valid for a specified time call reference that is specific to one cell 
site (or part of a cell site) and valid at least for one transaction. The size of the event label shall be 
10 bits. 

7.7.4.3 Implementation of scrambling labels 

The scrambling label shall be generated as an algorithmic combination of an network specific cell number 
and the essential part of the MNI (i.e. the MCC + MNC elements only). These identities shall be used as 
the "seed 1 ' for the colour code scrambling function with every transmission or reception as described in 
ETS 300 392-2 [17], clause 8. 

NOTE: At the receive side, there is assumed to be no extraction of the scrambling label. An 
erroneous reception would only be detected by the normal channel coding as a 
decoding failure. This means that the receiver need not distinguish between different 
errors (e.g. errors due to noise, fading, Doppler or errors due to a co-channel 
interferer). 
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7.7.5 Use of identities for V+D control channels 

The following rules shall apply to all V+D control (signalling) channels. 

MAC PDUs may be addressed with either an event label or an SSI or SMI. The SSI used for an SSI shall 
be used for all unreserved uplink MAC PDUs. This shall be: 

a) the ISSI or ASSI value that has been allocated by this network. For migrating mobiles this shall be 
the visitors (V)ASSI; or 

b) anUSSI;or 

c) a GSSI. 

NOTE 1 : The use of USSI is indicated within the message. 
The following rules give the precise usage: 

1) for MS originated calls and all layer 3 responses to MS terminated group calls, the MS shall use the 
ISSI or ASSI if one is available. The ASSI shall be used in preference to an ISSI if both are 
available. An USSI shall only be used if no valid SSI is available; 

NOTE 2: An USSI should only be used for the first access to a new (visited) TETRA network. 
This should be followed by an identity exchange to obtain a (V)ASSI. 

2) for MS terminated individual calls (ISSI, ASSI), the MS shall reply with the same SSI as used by the 
BS; 

3) for MS terminated management calls (STMI), the MS shall reply with the STMI; 

4) on the uplink, a GSSI is used in the MAC header only for the layer 2 group presence indication. 

When required, the USSI shall be generated by the MS by copying an existing home ISSI (i.e. an ISSI 
allocated by a different home network). 

On reserved access, the allocated event label should be used to replace SSI. 

7.7.6 Labelling of packet channels 

All MAC PDUs shall contain a SSI or a locally allocated event label. Event labels shall be used for all data 
transfers that require multiple bursts. 

NOTE: The first burst of a data transfer will usually include the ISSI or ASSI. Therefore the 
event label offers no advantage for data transfers that only occupy a single burst. 

Event labels may be used for any MAC PDU (both user data and control). 

7.7.6.1 Use of identities for uplink data transfers 

Uplink PDUs shall only be addressed with a SSI. The SSI used for uplink MAC PDUs shall be either: 

a) the ISSI or ASSI value that has been allocated by this network. For migrating mobiles this will be the 
visitors (V)ASSI; or 

b) an Un-exchanged Short Subscriber Identity (USSI). 
The type of SSI in use shall be indicated in the MAC PDU. 
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An ASSI or ISSI shall be used if one is available and the ASSI shall be used in preference to an ISSI if 
both are available. An USSI shall only be used if no valid value is available. 

NOTE: An USSI is only used for the first access to a new (visited) TETRA network. This is 
followed by an identity exchange to obtain a (V)ASSI. 

When required, the USSI shall be generated by the MS by copying an existing home ISSI (i.e. an ISSI 
allocated by a home network). 

7.7.6.2 Use of identities for downlink data transfers 

Downlink PDUs may be addressed with either a SSI or a SMI. 
The SSI used for downlink MAC PDUs shall be: 

a) an ISSI; or 

b) an ASSI; or 

c) aGSSI;or 

d) the USSI used by the MS in the initial registration request. 

These alternative SSIs shall not be distinguished in the downlink MAC PDUs. 

The MS shall respond to all valid addresses on the downlink (all values of ISSI, ASSI, GSSI and SMI). In 
particular in the home TETRA network, it shall respond to a valid ISSI even if an ASSI is available for that 
family. 

7.7.7 System information broadcast 

Broadcast MAC PDUs (e.g. control messages) shall be unaddressed (i.e. they shall not contain any SSI 
address). These unaddressed messages shall be implicitly addressed to all MSs. 

7.7.8 Reserved value of group address for user information broadcast 

A specific SSI shall be reserved for broadcasting information to all MSs in a TETRA network. The content 
of the 24 bits shall be all ones (1). To broadcast information over the whole TETRA domain, a special TSI 
shall be obtained by adding a MNI containing all ones (1) to the previously defined SSI. Partial user 
broadcast shall be obtained by combining different MNI and SSI. 

This reserved address defines a group to which all MSs shall belong. For example it may be used as the 
distribution address for CMCE and S-CLNP calls. It may also be used by the SwMI for sending broadcast 
signalling messages. 

7.8 Use of individual addresses 

The use of TETRA addresses (notably the ITSI and ISSI) for the air interface is outlined in the following 
subclauses. 

7.8.1 Air interface addressing functions 

The address functions for all layers are summarised in table 1 . 

NOTE: Table 1 only considers address related functions. Refer to the protocol architecture in 
clauses 5 and 6 for details of other functions. 
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The overview through all layers of the functions related to the addresses are illustrated in figure 33. 



Table 1 : Addressing functions per layer 



Layer 


Protocol 


Addresses used 


Address function 


3 


CONP 


No TETRA addresses 


End-to-end routing 






(X.121 source+dest) 




3 


S-CLNP 


ITSI/ISSI 


End-to-end routing 


3 


CMCE 


ITSI/ISSI 


End-to-end routing 


3 


MLE 


ISSI 


internal endpoint routing 








address management 


2 


LLC 


SSI 


Virtual frame address (PDO) 










2 


MAC 


SSI and/ or 


Uplink burst addressing 






Event label 


Battery saving/wake-up (PDO) 








Battery saving (V+D) 








Downlink filtering 


1 


PHL 


Scrambling label 


Scrambling 



7.8.2 Address placement in primitives and PDUs 
7.8.2.1 Use of ISSI at layer 2 

The placing of the SSI addresses into primitives and PDUs is shown in figure 33. Although the SSI is a 
layer 3 address, it shall also be used in the air interface layer 2. 

The relevant SSI address shall be supplied to layer 2 by the MLE. It shall appear in the layer 2 primitives 
as a separate parameter: i.e. it shall remain visible down to the MAC layer. This SSI address shall only be 
"invisible" at the physical layer. 

This SSI parameter shall be the SOURCE-SSI in request primitives (i.e. at the sending side) and shall be 
the DESTINATION-SSI in the indication primitives (i.e. at the receiving side). 

In all cases, the SSI shall be the value allocated by the current network. For a migrating terminal this shall 
be the (V)ASSI allocated by the visited system (see subclause 7.7). 

The SSI mentioned as the source address shall not be a group address (GSSI), except in the case of the 
layer 2 group presence indication. 

At the sending side, the MAC layer may place the source SSI into any suitable uplink PDUs unless an 
event label has been assigned. The MAC may choose to only send the ISSI in the first burst. It may then 
substitute an event label at any time, and may then use this event label to label future MAC bursts for the 
same ISSI. 

At the receiving side the MAC layer may have received the destination ISSI at any time (e.g. in a previous 
message) and may only receive an event label in a particular burst. Nonetheless it shall always provide 
the destination ISSI as a parameter in each indicate primitive (i.e. convert any event labels to the 
associated ISSI). 



INITIAL MESSAGES (e.g. Setup Messages)! 
L3 / CONP / uplink and downlink 

L3 / CMCE or S-CLNP / downlink 

L3 / CMCE or S-CLNP / uplink 
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Figure 31: Message addressing for initial messages 

A call set-up message using random access in V+D shall use the SSI. 



7.8.2.2 Use of ITSI/ISSI at layer 3 

7.8.2.2.1 Use of ITSI/ISSI by S-CLNP 

The ITSI and ISSI addresses shall be used as the routing address for all S-CLNP packets, where the PDU 
routing shall be defined by the source and destination ITSI (or ISSI). 

The ISSI shall be used for all intra-TETRA calls. The ITSI shall be used for inter-TETRA calls. As usual, 
alias identities shall replace individual addresses if appropriate. 

When migrating, the S-CLNP shall retain its home network (H)ITSI, and calls to this subscriber should 
continue to use the (H)ITSI as the layer 3 destination address. The visitors (V)ASSI shall be used for all air 
interface PDUs in the visited network, and translation between the home (H)ITSI and the visitors (V)ASSI 
shall be performed by the visited network. 

NOTE: The (V)ASSI is a temporary exchanged address, and the association to a given 
subscriber may be changed at any time by the visited network. 
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The S-CLNP packet header over the air interface is designed to be as short as possible. As a result, three 
different PDUs have been defined for S-CLNP as described in ETS 300 392-2 [17], clause 22: 

S1_DT PDU: 

used on the uplink, and contains only DESTINATION-ITSI (or ISSI); 
S2JDT PDU: 

used on the downlink, and contains only SOURCE-ITSI (or ISSI); 
S3JDT PDU: 

used for inter-system inter-working and contains both DESTINATION- and SOURCE-ITSI. 

There shall only be one address field in the uplink and downlink PDUs to remove the duplication with the 
MAC layer address (the other ISSI address shall appear in the layer 2 primitives as described above). 
These air interface PDUs shall use shortened ISSI addresses (instead of the full ITSI) for addressing 
within one TETRA sub-domain. 

The infrastructure shall convert between these different PDUs as required. 
7.8.2.2.2 Use of ITSI/ISSI by CMCE 

The ITSI, ISSI and GSSI shall be used as the routing address for CMCE, where the call routing shall be 
defined by the source and destination ITSI, ISSI or GSSI, and/or the call identifier. 

The ISSI shall be used for all intra-TETRA calls for both source and destination. The ITSI shall be used for 
inter-TETRA calls as destination address. As usual, alias identities shall replace individual addresses 
when appropriate. 

For external calls, the first message should follow the internal (TETRA) procedure to access a gateway 
and further addressing related to the network type should be provided in a subsequent message. 

When migrating, the CMCE shall retain its home network ITSI, and calls to this subscriber shall continue 
to use the ITSI as the layer 3 destination address. The visitors (V)ASSi shall be used for all air interface 
PDUs in the visited network, and translation between the home ITSI and the visitors (V)ASSI shall be 
performed by the visited network. 

NOTE: The (V)ASSI is a temporary exchanged address, and the association to a given 
subscriber may be changed at any time by the visited network. 

The CMCE header over the air interface is designed to be as short as possible. As a result, different 
PDUs have been defined for CMCE using the different addresses described in this clause. The CMCE 
PDUs are further described in ETS 300 392-2 [1 7], clause 1 4. 

For the ISI, the PDU shall contain the full addresses (TSI) for both source and destination. 

There shall only be one address field in the uplink and downlink PDUs at layer 3, respectively destination 
and source, to remove the duplication with the MAC layer address (the other ISSI address shall appear in 
the layer 2 primitives as described above). These air interface PDUs shall use SSI (instead of the full ITSI) 
for addressing within one TETRA sub-domain. 

The infrastructure shall convert between these different PDUs as appropriate. 
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Figure 32: CONP and S-CLNP air interface addressing 
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Figure 33: CMCE V+D air interface addressing 
7.8.3 Routing principles 

7.8.3.1 Routing of intra-TETRA calls (within one TETRA network) 

Within one TETRA network, packet routing may use NSAP or SSI. 

SSI alone should be sufficient for intra-TETRA call routing and SSI-only operation should be used for V+D 
calls. Dual addressing (SSI plus NSAP) should be used as a V+D option for "telephony access". However, 
dual addresses (SSI and NSAP) may be used for all intra-network routing as an operator choice. 

Dual addressing shall be used for CONP calls, i.e. both the X.121 (NSAP) address and the ITSI shall be 
allocated by the TETRA network operator. 

7.8.3.2 Routing of inter-TETRA calls (between two TETRA networks) 
Between two TETRA networks, packet routing may use NSAP or TSI. 

TSI alone should be sufficient, and TSI-only operation should be used for most V+D calls. However, dual 
addresses (TSI and NSAP) may be used as an operator choice in packet mode services. 
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7.8.3.3 Routing of external calls (to/from non-TETRA networks) 

External to a TETRA network routing shall only use NSAP addresses. 

The ISSI (or ASSI) shall still appear in the set-up packet for initial access to support the TETRA 
procedures. 

7.8.4 Address and identity comparison 

TETRA addresses and identities are compared in table 2 to the ones used in other systems. 



Table 2: Comparison of addresses and identities between TETRA and other systems 



TETRA 


GSM 


NA7/ UPT 


Notes 


ITSI 


IMS) 






GTSI 






4 


ISSI 


MSIN 


Personal Identity 


1,2,3 


ASSI 


TMSI 






GSSI 






4 


TMI 


IMEI 


Terminal Identity 


2,3 


TEI 








NSAP 


MS-ISDN or 
X.25 


Personal or 
Terminal Number 


3 


NOTE 1 : Refer also to CCITT Recommendation E.21 2 [3]. 

NOTE 2: Both the ITSI and the IMS! may be removable (transferable) identities. The TMI, the TEI 

and the IMEI are not removable. 
NOTE 3: NA7/ UPT makes an important distinction between Identities and Numbers. 
NOTE 4: Only TETRA recognises group addressing. 



8 Overview of circuit mode basic services 



8.1 Introduction 

This clause identifies a technical realisation for the circuit mode services showing signalling between 
users on the U-plane and C-plane. 

8.2 Functional groupings in circuit switched mode calls 

8.2.1 Circuit switched call control, C-plane 

Functions shall exist in the TETRA SwMI that can be accessed for setting up a basic service or 
performing a supplementary service process. The circuit mode applications shall invoke these services 
through SAPs at the top of the CMCE. 

In the case of a circuit switched call, the C-plane shall be switched to the U-plane after the SwMI has 
given permission for the call to be set-up, and user data may be transferred, (this may be in the form of 
speech or data depending upon the application). 

8.2.2 Circuit switched call, user data, U-plane 

The propagation of circuit mode data, which shall not include control information, from point-to-point and 
point-to-multipoint shall be done on the U-plane. Examples of such data can be TETRA encoded speech, 
circuit mode speech and circuit mode data. 

8.3 Protocols 

Different types of protocols shall be required to convey information from different entities in one unit to 
another entity in another unit. The different protocols are described in the following subclauses. 
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8.3.1 TNP1 

The TETRA specific layer 3 protocol between peers within a MS or LS over the Rj reference point to 
external TE. 

8.3.2 TNP2 

In order that the TETRA specific CMCE protocol can be supported between the LS and the SwMI across 
an ISDN network the TNP2 protocol shall be used. 

8.3.3 TNP3 

The TNP3 protocol shall be used to convey the CMCE and the MM protocol over the ISI. 

8.3.4 TNP4 

The TNP4 protocol shall be used to convey the TETRA specific CMCE protocol between the MS and the 
SwMI over the air interface (Urn). 

8.3.5 AM 

The TETRA specific layer 1 protocol shall be conveyed between the MS and the SwMI over the air 
interface (Urn). 

8.3.6 AI2 

The TETRA specific layer 2 protocol shall be conveyed between the MS and the SwMI over the air 
interface (Urn). 

8.3.7 TLC1 

The TLC1 protocol shall be used as the layer 2 protocol on the C plane, between an external terminal and 
an MS or LS over the Rt reference point. 

8.3.8 V.24T 

The V.24T protocol shall be used to manage the physical layer between an external terminal and an MS 
or LS over the Rj reference point. 
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8.4 Example configuration 
8.4.1 MS to MS 

Figure 34 shows how CMCE data shall be exchanged between MS and SwMI. 
MS SwMI 
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Cct Mode 
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TNP4 



AI-2 
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TETRA Functions 
for CMCE 


TNP4 


TNP4 


AI-2 


AI-2 


AI-1 


AI-1 



Cct Mode 
Applications 



TNP4 



AI-2 



AI-1 



Circuit (Cct) 

Figure 34: MS connected to MS, exchange of CMCE information, C-plane 

Figure 35 shows how user data on the U-plane shall be exchanged between two MSs over a LLC bridge in 
the SwMI. 
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(c) 
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(a) Circuit Mode applications 

(b) TETRA encoded speech 

(c) Encryption 



Figure 35: MS connected to MS, exchange of user data, U-plane 
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8.4.2 



MS to LS 



Figure 36 shows how CMCE data shall be exchanged between MS and SwMI and LS and SwMI by 
means of the TNP2 and TNP4 protocol. 
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(a) Circuit Mode Applications 
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Figure 36: MS connected to LS, exchange of CMCE data, C-plane 

Figure 37 shows how speech on the U-plane shall be exchanged between a MS and a LS over a SwMI. 
The TETRA encoded speech over the air interface shall be transcoded to A-law PCM encoded speech 
over the ISDN network. 
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(a) ISDN Application 



Case: TETRA encoded speech, transcoding in SwMI 

Figure 37: MS connected to an ISDN, telephone exchange of speech, U-plane 

Figure 38 shows how TETRA encoded speech and circuit mode data on the U-plane shall be exchanged 
between a MS and a LS over a SwMI. The TETRA encoded speech, sent over the air interface, shall be 
rate adapted and sent in an Unrestricted Digital Data (UDD) channel of 64 kbit/s over the ISDN network. 
The TETRA encoded speech shall then be rate adapted back to its original rate in the LS, and decoded in 
the LS application. 
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Figure 38: MS connected to LS, exchange of user data, U-plane 
8.4.3 MS and LS connected over user-interface (Rt reference point) 

Figure 39 shows how CMCE data shall be exchanged between application and termination in MS and LS 
by means of TNP1 , TNP2 and TNP4 protocol. Figure 39 also shows how MT and SwMI and SwMI and NT 
shall exchange data. 
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Figure 39: MS (asynch terminal connected to MT in Rt ref. point) connected to LS, (ISDN terminal 
connected to NT in St ref. point) - exchange of CMCE data, C-plane 
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Figure 40 shows how circuit mode data on the U-plane shall be exchanged between a MS and a LS over 
the Rt reference point. TETRA encoded speech shall not be envisaged for this configuration. 
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Figure 40: MS (asynch terminal connected to MT in Rt ref. point) connected to LS, (ISDN terminal 
connected to NT in St ref. point) - exchange of user data, U-plane 



8.4.4 MS to MS over ISI 



Figure 41 shows how CMCE data shall be exchanged between SwMI's by means of the TNP3 protocol. 
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Figure 41 : MS connected to MS via ISI - exchange of CMCE data, C-plane 
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Figure 42 shows how TETRA encoded speech on the U-plane shall be exchanged between MSs over ISI, 
with transcoding. In this case two TETRA-PCM transcodings shall be required. 
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Figure 42: MS connected to MS via ISI - exchange of user data, U-plane 

Figure 43 shows how TETRA encoded speech and circuit mode data on the U-plane shall be exchanged 
between MSs over ISI. 
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Figure 43: MS connected to MS via ISI - exchange of user data, U-plane 
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9 Mobility Management (MM) in MS 

9.1 Introduction 



This clause deals with the network signalling aspects of registration, authentication, energy economy 
mode change signalling and enable/disable signalling. 

9.2 Overview of MM relations and procedures 

Figure 44 and figure 45 show the MM relations, stimulations and procedures on the MS side. The 
distinction between the MS MM and SwMI MM entities are presented in the scenarios. 
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Figure 44: MM relation 
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9.3 Stimuli of MM 

9.3.1 Stimulation through TNMM-SAP 

ITSI attach: when an ITSI is attached after previously having been detached, this shall be reported 
to the MM. An ITSI may be attached by a registration request or at subscription. 

Examples of events that should cause an ITSI attach are: . 

entering of a SIM card containing the ITSI into the MS; 

"reset button"; 

power up. 

ITSI detach: when a ITSI is detached after previously having been attached, this shall be reported 
to the MM. The way an ITSI is detached can be in a number of different ways. It shali be reported to 
the MM via the TNMM-SAP by a primitive request. 

Examples of events that should cause an ITSI detach are: 

removal of the SIM card containing the ITSI from the MS; 

power down. 

registration on demand: registration may be requested by the user to force the registration and/or 
the authentication procedure. It shall be reported to the MM via the TNMM-SAP by a primitive 
request with cause "registration on demand"; 

network authentication on demand: authentication shall be requested by the user to force an 
authentication of the TETRA infrastructure (base station). The authentication may be invoked by an 
"authentication button"; 

energy economy mode change: the change of an energy saving scheme shall be requested by 
the user. It shall be reported to the mobility management peer in the infrastructure. 

9.3.2 Stimulation through LMM-SAP 

Stimulations through the LMM SAP are defined in ETS 300 392-2 [17], clause 18 and may be any of the 
following: 

intervention: whenever the MM is required to take over control of the roaming or migration 
processes either by performing registration/authentication or by performing activation; 

roaming: the change of a LA within the TETRA network may require registration; 

forwarding: the change of a LA within the TETRA network while still using the previous shall 
require registration; 

migrating: the change of a LA from one TETRA network to another shali require registration. 

9.3.3 Stimulation through peer MM 

Stimulation through peer MM shall be achieved by sending PDU (messages) between the peer entities. 

location update command: the peer MM shall be able to force registration by the message 
<Location update command>; 

location acceptance: the peer MM may accept a location registration of a MS or refuse it; 

network initiated user authentication: the peer MM shall be able to start an authentication 
independent of registration by means of the message Authentication Demand>; 



Page 70 

ETS 300 392-1: February 1996 

temporary disable: the peer MM shall be able to temporary disable a MS by sending the <Disable> 
message; 

enable: the peer MM shall be able to enable a MS temporary disabled by sending the <Enable> 
message; 

permanent disable: the peer MM shall be able to permanently disable a MS by sending the 
<Disable> message. 

9.3.4 Other stimulation 

periodic registration: registration may be ordered to be performed periodically when a timer 
expires. The value of the timer shall be stored in the MS data base. 

9.4 Outputs from MM 

9.4.1 Output through TNMM-SAP 

registration and authentication result: the result of the registration and authentication 
procedures shall be reported via the TNMM-SAP by indication and confirm primitives: 

for a successful registration; 

for a successful authentication; 

for an unsuccessful authentication; 

for an unsuccessful registration; 

for a successful detach; 

for disabling/enabling. 

temporary disabled: the order to temporary disable the MS shall be reported via the TNMM-SAP 
by a primitive indication with cause "temporary"; 

temporary enabled: the order to temporary enable the MS shall be reported via the TNMM-SAP by 
a primitive indication; 

permanently disabled: the order to permanently disable the MS shall be reported via the 
TNMM-SAP by a primitive indication with cause "permanently". 

9.4.2 Outputs through LMM-SAP 

Outputs from the LMM SAP are defined in ETS 300 392-2 [17], clause 17. 

MM activates MLE: MM shall control the LAs wherein the MS may search for service by activating 
the MLE. 

9.4.3 Output to peer MM 

The messages to the MM peer entity shall be any of the following: 

authentication demand: when using the MS invoked authentication a message authentication 
demand> shall be sent to the infrastructure; 

authentication reply: when using the network initiated authentication a message authentication 
reply> shall be sent to the infrastructure; 

ITSI detach: when the ITSI detach is reported to the MM by a request, and the operator option of 
ITSI detach report is invoked, a message <ITSI detach> shall be sent to the peer MM; 
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location update demand: MS shall request the infrastructure to update the location information of 
the MS with a message location update demand>; 

status: MS shall report the energy saving mode to the infrastructure with a message <status>. 

9.5 Database requirement 

The identified data base requirements in the mobile for MM use are: 

authentication parameters: the keys for authentication parameters shall be stored in the data 
base; 

ITSI detach report: it shall be stored in the MS data base wether if ITSI detach is shall be reported 
to MM in the infrastructure or not; 

the search area: the total area in which the mobile may search for service. 

9.6 MM procedures 
9.6.1 Registration 

Location registration procedures in MS should be chosen by the network operator. 
9.6.1 .1 Registration at roaming 

9.6.1 .1 .1 Implicit registration 

A network can be run so that no registration is needed. To keep track of where the MSs are situated, 
implicit registration should be used. This registration should be performed when a MS is sending, e.g a 
CC message, or is responding, e.g. to a CC message. 

9.6.1 .1 .2 Multiple registration 

Multiple registration is when a MS is keeping its registration (for a finite or infinite time period) to a LA 
when it moves to and registers in a new LA. Effectively, the current RA is enlarged. Multiple registration 
can also be pre-arranged by the operator arrangement. However, the function is not considered in the 
scope of this ETS. 

9.6.1 .1 .3 Registration procedure 

The process shall start in the MS when another LA is preferred or when the MS is activated. The message 
<Location Update Demand> shall be sent to the infrastructure (see figure 46). The ISSI shall be used as 
sender identity. The database should be interrogated. If the request is granted, and if authentication is not 
performed together with the registration, the message <Location Update Accept> shall be returned. 
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Figure 46: Registration at accepted roaming, with no authentication nor identity exchange 

In the <Location Update Accept> message all LAs the MS may use without re-registering shall be included 
together with an indication of how long these LAs are valid. The MS may be registered in more than one 
LA. 

If the registration is not granted for some reason, e.g. overload, network failure or MS access deny, the 
message <Location Update Reject> shall be returned with the cause for the reject (see figure 47). 
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Figure 47: Registration at not accepted roaming, with authentication and no identity exchange 
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9.6.1.1.4 



Registration with authentication 



The network initiated authentication process (see subclause 9.6.2.1) may be included in the registration 
process (see figure 48). 
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Figure 48 Registration at accepted roaming, with authentication and no identity exchange 



9.6.1.1.5 



Registration with identity exchange 



When the message <Location Update Demand> is sent to the infrastructure (see figure 49), an ASSI if 
available, shall be used for sender identity. This ASSI should be translated in the infrastructure to the 
correct ITSI to gain access to the correct entry in the database. The first time the identity exchange is 
carried out, it shall be the ISSI which is used in the <Location Update Demand>. The infrastructure may 
then return the new identity in the form of an ASSI. This new identity should now be used hereafter (see 
figure 50). 



The authentication process may be included as described in subclause 9.6.1 .1 .4. 



If the demanded authentication and registration are granted, a new ASSI may be sent to the MS. This new 
ASSI shall be used in subsequent communications with the network. 



Page 74 

ETS 300 392-1: February 1996 



MS 



Air Interface 

U-Location Update Demand 
ISSI) 



D-Authentication Demand 
(Type of Auth.) 



U-Authentication Reply 
[Resp. or TEI) 



D-Location Update Accept 
(ASSI) 



BS 



SwMI/RPDI 



Update LA 



Authenticate 



Authentication Reply 
Update Accepted 



HDB 



D-Authentication Demand 
(Type of Auth.) 



U-Authentication Reply 
[Resp. or TEI) 



D-Location Update Accept 
(New ASSI) 



Figure 49: Registration at accepted roaming, with authentication and first identity exchange 
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Figure 50: Registration at accepted roaming, with authentication and subsequent identity 

exchange 
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9.6.1.2 



Registration at migration 



9.6.1.2.1 



Registration with identity exchange 



When roaming, the process shall start in the MS when another LA, in another network, is preferred or 
when the MS is activated. The message <Location Update Demand> shall be sent to the infrastructure 
(see figure 51). In this case, the USSI shall be used for sender identity. 

For V+D, this USSI shall be identified by the visited infrastructure which then immediately shall assign a 
(V)ASSI by sending a <Location Update Proceeding> message with the assignment of a (V)ASSI. The MS 
shall continue the information exchange with the SwMI with the (V)ASSI. The <Location Update Demand> 
shall now be repeated with the new (V)ASSI and with the full TETRA subscriber identity (ITSI) as 
parameter. 
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Figure 51: Registration at accepted migration, with identity exchange and no authentication (V+D) 

For PDO (see figure 52) the <Location Update Demand> using the USSI shall contain the full TETRA 
subscriber identity (ITSI) as parameter. No <Location Update Proceeding> message should be needed. 
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Figure 52: Registration at accepted migration, with identity exchange and no authentication 

The visited infrastructure and possibly also the home infrastructure shall identify the ITSI. After this 
identification procedure, the MS should have an entry in the Visited Data Base (VDB) which should mirror 
the Home Data Base (HDB) as closely as possible. 

After registration is accepted, the HDB shall be updated. This update may include services not supported 
by the visited TETRA. Any entry in another VDB should be erased by the home system. 

Furthermore after accepted registration, the <Location Update Accept> message including new (V)GSSIs 
and (V)ASSI parameters shall be sent to the MS. These new (V)GSSIs and (V)ASSI shall be used in 
subsequent communications with the network. Subsequent changes of LA in the same visited system 
shall be regarded as roaming, not migration. 
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9.6.1.2.2 



Registration with authentication 



For V+D there shall only be one type of identity exchange based upon the USSI as outlined in 
subclause 9.6.1.2.1, (see figure 53). 
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Figure 53: Registration at accepted migration, with identity exchange and authentication (V+D) 
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For packet mode data transfer the USSI shall be used during all the message exchanges and until a 
(V)ASSI has been assigned after <Location Update Accept> (see figure 54). 
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Figure 54: Registration at accepted migration, with identity exchange and authentication 

If authentication and registration are granted new (V)ASSI and (V)GSSIs shall be sent to the MS. These 
new (V)ASSI and (V)GSSIs shall be used in subsequent communications with the network. 



9.6.1.3 



Network initiated registration 



The network shall force the MS to initiate a location update procedure. This shall be activated by the 
<Location Update Command> message, (see figure 55). 
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Figure 55: Network initiated registration 



9.6.2 



Authentication 



NOTE: Authentication mechanisms to be used in TETRA are described in ETS 300 392-7 and 
are outside the scope of this part of the standard. The following descriptions are 
informative. 
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9.6.2.1 Network initiated authentication 



It is possible for the network to authenticate a mobile without any previous MS initiated registration. This is 
done by sending the message Authentication Demand> t (see figure 56). 
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Figure 56: Independent authentication initiated by the network 



If the C/R method is selected, the network sends the challenge number to the MS in the Authentication 
Demand> message and the MS calculates the response and returns it to the network in the 
Authentication Reply> message. 

If the TEI method is selected, the MS calculates a 32 bits number based on a pre-defined encryption key 
and the TEI and returns the number in the Authentication Reply> message. 

If the authentication is not granted due to incorrect response, an Authentication Reject> message is 
returned, (see figure 57). 
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Figure 57: Registration at not accepted authentication, with authentication and no identity 

exchange 

In the <Location Update Accept> message, all LAs the MS may use without re-registering are included 
together with an indication of how long these LAs are valid. 



9.6.2.2 



MS initiated authentication 



It is possible also for a MS to start the authentication by sending the message Authentication demand> 
to the infrastructure, (see figure 58). 
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Figure 58: Authentication initiated by the MS 

If the C/R method is selected, the MS sends the challenge number to the infrastructure in the 
Authentication Demand> message and the infrastructure calculates the response and returns it to the 
MS in the <Location Update Accept> message. 



If the TEI method is selected, the infrastructure calculates a 32 bits number based on a pre-defined 
encryption key and the TEI and returns the number in the <Location Update Accept> message. 
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The MS will not accept the network if an incorrect response in the <Location Update Accept> message is 
returned. 

In the <Location Update Accept> message, all LAs the MS may use without re-registering are included 
together with an indication of how long these LAs are valid. 



9.6.3 



De-registration 



The individual (and group) TETRA subscriber identities (ITSI and GTSI's) may be stored in a card or as an 
application. If this identity is removed or the MS is powered down, as an operator option, an <ITSI 
Detach> message is sent to the infrastructure, (see figure 59). 
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9.6.4 



Figure 59: De-registration (ITSI detach) 
Periodic registration 



Registration of the MS to the network can be initiated periodically by an internal MS timer, the procedure is 
the same as described in figures corresponding to registration. 

9.6.5 Disable/enable 

9.6.5.1 Temporary disable 

It may, as an operator option, be possible to temporarily disable an MS, (see figure 60). The MS will on 
receipt of the message <Disable with parameter Temporary^ be prohibited from sending any further 
messages than MM messages over the air interface. This state remains until the message <Enable> is 
received. It is an operator option if an accepted authentication is performed before the disable order is 
executed. 
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Figure 60: Temporary disabling a MS 
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9.6.5.2 Temporary enable 

The message <Enable> is used to change an earlier "Temporary" <Disable> message, (see figure 61). 
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Figure 61 : Temporary enabling a MS 



9.6.5.3 



Permanently disable 



It may, as an operator option, be possible to permanently disable an MS, (see figure 62). The MS will on 
receipt of the message <Disable with parameter "Permanently^ be prohibited from sending and receiving 
any further messages than MM messages over the air interface. This state remains until the MS has been 
re-activated in an operator authorized service centre. It is an operator option if an accepted authentication 
is performed before the disable order is executed. 
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Figure 62: Permanently disabling a MS 



9.6.6 



Energy economy mode change 



The mode changes for MS energy saving mode are reported to the infrastructure, either in normal 
registration or as a separate action. One of the 8 different energy saving schemes (including <No energy> 
saving) is reported. 

9.7 Downloading of group identities 

The downloading of group identities may be performed by the MM entity. 

Dynamically defined GTSIs shall contain lifetime information (refer to SS-DGNA stage 2). During the 
migration process the visited system may allocate (V)GSSIs to be used instead of GSSI. 

Temporary group addresses shall be valid only for the lifetime of the call. 



9.7.1 



Add group identity 



When the infrastructure wants to add one or more group identities to the ITSI family in the MS, a <Group 
Identity Command> message shall be sent to the MS with the command "add list" (see figure 63). The MS 
either accepts the complete list or rejects the whole list. The accept or reject shall be sent to the 
infrastructure in a <Group Identity Acknowledge> message. 
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9.7.2 



Figure 63: Network group identity (GSSI) download 
Delete group identity 



When the infrastructure wants to delete one or more group identities in the ITSI family of the MS, a 
<Group Identity Command> message shall be sent to the MS with the command "delete list" (see 
figure 64). The MS shall then delete all GSSIs that can be found in the ITSI family and an acceptance of 
the command shall be sent to the infrastructure in a <Group Identity Acknowledge> message. 
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9.7.3 



Figure 64: Deletion of a list of group identities (GSSI) by the network 
Delete all group identities 



When the infrastructure wants to delete all group identities in a ITSI family of the MS, a <Group Identity 
Command> message shall be sent to the MS with the command "delete all" (see figure 65). The MS shall 
then delete all GSSI that belong to the ITSI family and an acceptance of the command shall be sent to the 
infrastructure in a <Group Identity Acknowledge> message. 
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Figure 65: Deletion of all group identities (GSSI) by the network 
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9.7.4 Report group identities 



When the infrastructure wants a report on the current group identities belonging to the ITSI family of the 
MS, a <Group Identity Command> message shall be sent to the MS with the command "report" (see 
figure 66). The MS shall then respond with a complete (or partial) list of GSSIs in the requested ITSI 
family. The list shall be sent to the infrastructure in a <Group Identity Acknowledge> message. 
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Figure 66: Reporting current group identities (GSSI) to the network 



9.8 Exception conditions 



9.8.1 Undisciplined de-registration 

Prior to changing the ITSI of a subscriber, the "old" ITSI shall be detached. Failure to do so will result in 
two identical ITSI operating in the TETRA network sharing one equipment identity. This will cause 
disturbance to the operation. 



10 MLE mobility scenarios and functionalities 



10.1 Introduction 

This clause deals with the functions which may be performed by the MLE sub-layer during mobility 
scenarios, both when roaming and migrating. 



10.2 Overview 



When a MS moves from cell-to-cell, the higher layer entities in the protocol stack may experience some 
interruption in the TETRA services. The MLE may perform certain functions which reduce the interruption 
caused by cell re-selection. 

These functions may be applied either to assist the MM of the MS, that is to keep track of the movements 
of the MS, or the functions may be applied to recover MLE connections between a MS and the SwMI 
during cell re-selection. The functions may also assist the recovery of communications (call restoration) 
during the cell re-seiection, but the specific communication recovery procedures are outside the scope of 
this ETS. The MLE connection recovery and the assistance of communication recovery may also be 
relevant after a temporary loss of coverage within the same cell. 

This clause gives a description of the functions and the different levels of capability that the MLE protocol 
shall support within TETRA. It gives also an overview of the different stimuli known to the MLE, including 
the MLE PDUs. The clause describes how these stimuli may be used by the MLE to support the MLE 
mobility functions. 
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10.3 MLE responsibilities 

MS-MLE shall be responsible for the following: 

manage the scanning for suitable cells using the relevant LAs and the cell selection/re-selection 
procedures for the MLE; 

manage the monitoring of neighbour cells by instructing the lower layers. The function may help the 
scanning process in ranking the cells; 

manage the surveillance of the serving cell by instructing the lower layers to provide quality 
information, when attached to the cell; 

manage the undeclared cell re-selection; 

invite MM entity intervention if no service is found, whereby guidance is received containing 
information on new LAs; 

invite MM entity intervention if a suitable cell is outside RA, whereby MM is envisaged to perform 
the registering procedure. 

SwMI/RPDI-MLE and MS-MLE shall be responsible for the following: 

manage the announced cell re-selection; 

manage the unannounced cell re-selection; 

advise the higher layer 3 entities of the potential of errors arising from a break in the MLE 
connection while attaching to another cell. The advisory is only supported by the MLE if higher 
layers have asked for a MLE connection; 

advise the higher layer 3 entities when a existing MLE connection has been terminated due to a 
lower layer failure; 

advise the higher layer 3 entities by the time MLE service is required, that due to ongoing cell 
re-selection service is not available; 

exchange network information via network information broadcast, this information is used by the 
initial cell selection and cell re-selection procedures. 

The MLE in the MS or SwMI may support a number of levels of TETRA system capability for the 
assistance of communications recovery or attachment recovery both with and without MLE connection. 
These are summarized in the following list: 

Initial cell selection; 

announced cell re-selection type 1 by roaming; 
announced cell re-selection type 2 by roaming; 
announced cell re-selection type 3 by roaming; 
unannounced cell re-selection by roaming; 
undeclared cell re-selection by roaming; 
announced cell re-selection type 1 by migrating; 
announced cell re-selection type 2 by migrating; 
announced cell re-selection type 3 by migrating; 
unannounced cell re-selection by migration; 



Page 86 

ETS 300 392-1: February 1996 



undeclared cell re-selection by migration; 



no MLE recovery. 



10.4 MS-MLE model 



In the scenarios that follow, the LCMC SAP is taken as an example of an LXX SAP. The services offered 
to the LCMC SAP during the scenarios that follow may be the same as for the other LXX SAPs. In 
particular, interactions for the circuit-mode service (V+D only) with the CMCE through the LCMC-SAP 
become: 

interactions with the CONP through the LCO-SAP; 

interactions for the connectionless packet service with the S-CLNP through the LSCL-SAP. 

For each scenario examined, two perspectives are considered: 
LMM SAP perspective (see figure 67); 

LCMC SAP perspective (see definitions and figure 67). 

NOTE: The layer to layer primitives shown on the SwMI side in the following scenarios are 
only informative and shown for the description of the model. 
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Figure 67: SAPs offered to the MS MLE 



10.5 



MLE functionalities 



The overall mobility functionalities as outlined in figure 67 can be broken down into different sub-functions. 
Each of these sub-functions are described by an individual scenario. These are: 

1 ) monitoring of neighbour cells (MS - side); 

2) scanning of neighbour cells (MS - side); 

3) MM Activation of MLE (MS - side); 

4) open up MLE services (SwMI/MS - side); 

5) closing MLE services (SwMI/MS - side); 
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6) changing to the serving cell (MS - side); 

7) surveillance of the serving cell (MS - side); 

8) inviting MM intervention when no service is found (MS - side); 

9) inviting MM intervention when found LA is outside RA (MS - side); 

1 0) set-up MAC broadcast (SwMI - side); 

1 1 ) initiating MLE broadcast (SwMI - side); 

1 2) MM registering (MS - side); 

13) announce old cell and to-to-channel (MS/SwMI - side); 

14) announce old cell (MS/SwMI - side); 

15) announce new cell and successful restoration (MS/SwMI - side); 

1 6) announce new cell and restoration failure (MS/SwMI - side); 

17) path lost to the serving cell (MS - side). 



10.5.1 



Monitoring of neighbour cells (Scenario 1) 



Monitoring of the neighbour cells is started by issuing a TL-MON ITOR-LIST request primitive from the 
MS-MLE to the lower layers at the TLC-SAP. Before starting the monitoring, the MS-MLE should have 
received a <D-BROADCAST> PDU containing information of neighbour cells. The parameters to the 
TL-MONITOR-LIST request primitive are a list of cell-ids and the corresponding broadcast information 
from the <D-BROADCAST> PDU. The lower layers shall then be instructed to perform power 
measurements and path loss calculations concurrently with other services. The measurement method and 
the monitor function are described in ETS 300 392-2 [17], clause 23. When a measurement on one 
neighbour cell is finished, the result should be passed up to the MS-MLE in a TL-MONITOR indication 
primitive. The path loss result C2 for the concerned cell should be passed as a parameter. Based upon 
the individual C2 results from each of the neighbour cells, the MS-MLE should build a ranking list. The 
scenario is outlined in figure 68. 
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Figure 68: Monitoring of neighbour cells (Scenario 1) 
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10.5.2 Scanning of neighbour cells (Scenario 2) 

The scanning procedure seen from the MS-MLE may be a procedure in several steps employing a 
scanning list. This list can be built using various inputs such as: 

the result from the ranking of the neighbour cells performed by the monitoring sub function; 



a stored cell list; 



the result of the MLE-ACTIVATE request primitive; 



preference for certain cells. 

The scanning is started by issuing a TL-SCAN request primitive from the MS-MLE to the lower layers at 
the TLC-SAP. Each scan shall be performed on only one neighbour cell. The parameters sent in the 
primitive are apart from a scanning list element, the measurement method to be utilized at the lower 
layers. The measurement methods applied to the scanning may be: 

foreground measurements; or 



background measurements; or 

interrupted measurements. 

The measurement methods are described in ETS 300 392-2 [17], clause 23. Based upon the TL-SCAN 
request primitive parameters, the lower layers should be instructed to perform power measurements and 
to synchronize and read the information from the SYNC broadcast and the SYSINFO broadcast. When 
the lower layers have finalized their task, a TL-SCAN confirm primitive should be issued to the MS-MLE. 
Information about the scanned cell should be returned as parameters including the calculated path loss 
Ci. 



From now on, the path loss parameter Ci shall be returned in a TL-SCAN-REPORT indication primitive 
every time the monitor process (scenario 1, figure 68) has retrieved the power measurement. The 
MS-MLE may now choose to continue the scanning process or wait to see whether the scanned cell 
increases its Ci parameter. 
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Figure 69: Scanning of neighbour cells (Scenario 2) 
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1 0.5.3 MM activation of the MS-MLE (Scenario 3) 



Activation of the MS-MLE should be performed by the MM entity. The activation process should be started 
by the MM issuing a MLE-ACTIVATE request primitive to the MS-MLE. The LAs containing the cell-ID in 
which the MM empowers the MS-MLE to search for service in should be passed as parameters to the 
primitive. The cell-ID may be the preferred cells for the LAs. 

The MS-MLE then should start scanning procedure according to subclause 10.5.2 and when a suitable 
cell is found, the selection procedure according to subclause 10.6 should be applied. The measurement 
method, given as parameter to the lower layers in the TL-SCAN request primitive, should be foreground 
measurement. The method is described in ETS 300 392-2 [17], clause 23. 

NOTE: The activation of the MS-MLE may start with monitoring according to scenario 1 (see 
figure 68). Since it is an initial monitoring, the broadcast parameters on neighbour cells 
may not be known to the MS-MLE and therefore default values should in this case be 
assigned. 

When the activation process has finished, the MS-MLE should inform the MM about the result in a 
MLE-ACTIVATE confirm primitive. The result may either be that no suitable cells could be found or that 
the MS is now camped on the cell. In both cases, the MS-MLE should wait for intervention from the MM. 
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Figure 70: MM activation of the MS-MLE (Scenario 3) 



1 0.5.4 Open up MLE service (Scenario 4) 



The MM should decide when to open up for MLE services. When the MM issues an MLE-OPEN request 
primitive to the MLE this opens up the MLE services both in the MS and in the SwMI. In order to 
synchronize the events, signalling between the MM entities in the MS and in the SwMI shall take place 
before the employment of the "open-up-MLE-service" function. After reception of the MLE-OPEN request 
primitive, the MS-MLE and the SwMI-MLE should issue a MLE-OPEN indication primitive to their service 
users, e.g. CMCE, CONP and S-CLNP. After this sub-function is performed, the MLE service users 
should have access to the communication resources. 
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Figure 71 : Open up MLE services (Scenario 4) 
Close of MLE service (Scenario 5) 



The MM should decide when to close for MLE services. When the MM issues an MLE-CLOSE request 
primitive to the MLE this closes MLE services both in the MS and in the SwMI. In order to synchronize the 
events, signalling between the MM entities in the MS and in the SwMI can take place before the 
employment of the "close-of-MLE-service" function. After reception of the MLE-CLOSE request primitive, 
the MS-MLE and the SwMI-MLE should issue a MLE-CLOSE indication primitive to their service users, 
e.g. CMCE, CONP and S-CLNP. After this sub-function is performed, only the MM entity shall have 
access to the communication resources. All other MLE SAPs shall be closed. 
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Figure 72: Close of MLE services (Scenario 5) 



10.5.6 Changing to serving cell (Scenario 6) 

When MS-MLE decides to change to another cell, it should issue a TL-SELECT request primitive to the 
lower layers. The cell-ID (channel number) and some rules for surveillance of the serving cell should be 
provided as parameters. The lower layers should immediately change to the identified cell and start the 
survey. The TL-SELECT confirm primitive should be sent back to the MS-MLE indicating whether the 
selection has been successful or not. 
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Figure 73: Changing to serving cell (Scenario 6) 
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10.5.7 Surveillance of the serving cell (Scenario 7) 

The MS-MLE should start surveillance of its serving cell when selection of the cell is performed by utilizing 
the TL-SELECT request/confirm primitives. From now on, the MS-MLE should receive 
TL-MEASUREMENT indication primitives containing quality information from the lower layers and network 
broadcasts from the SwMI-MLE. The quality parameters in the TL-MEASUREMENT indication primitives 
should also contain the calculated path loss (refer to ETS 300 392-2 [17], clause 23) and may also 
contain message error rate, indication of random access failure and re-transmission failure on the LLC 
link. The <D-BROADCAST> PDU from the serving cell should contain information about neighbour cells 
and may also contain network information related to the serving cell. 



MS 



SwMI 



MM 



MLE selects cell by 
instructing the lower 
layers to use the channel 

The lower layers confirms 
that the channel shift has 
been done 

MLE receives quality 
information from 
the serving cell 

Broadcast with network 
information received 
from the serving cell 

MLE receives quality 
information from 
the serving cell 



CMCE MLE LLC 
TL-SELECT 
request 



LLC 



MLE 



CMCE 



MM 



4 



TL-SELEC 
confirm 



TL-MEASUR 
ndication 



Tl-UNITDATA 
indication 



4 



TL-MEASUR 
ndication 



:MENT 



EMENT 



TL-UNITDAT<\ 



quest 



Figure 74: Surveillance of the serving cell (Scenario 7) 
10.5.8 Inviting MM intervention 
10.5.8.1 No service can be found (Scenario 8) 

After scanning or due to sudden loss of radio contact, the MS-MLE may invite MM entity intervention in 
order to receive instructions for new LAs. When the MS-MLE cannot obtain service using its current 
understanding of the network, it should send a MLE-ACTIVATE indication primitive to the MM entity with 
parameters containing information about the reason why to invite MM entity. The parameters may be the 
current LA, the current serving cell and some other network parameters which MS-MLE has obtained via 
the network broadcast. 



After sending of the MLE-ACTIVATE indication primitive, the MM should proceed with a normal MLE 
activation as described in subclause 10.5.3. 
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Figure 75: Inviting MM intervention - no service can be found (Scenario 8) 
LA found outside RA (Scenario 9) 



When MS-MLE finds a cell in a LA which is outside the current FtA, it should invite MM entity intervention. 
As soon as the MS-MLE has discovered that the obtained LA is outside the RA, it should send a MLE- 
LINK indication primitive to the MM entity. The new LA in which the MS-MLE wants the MM to register in 
should be provided as a parameter. Then the MM register procedure should take place as described in 
subclause 10.5.1 1 and according to clause 9. When the MM is satisfied with the new LA, it should send a 
MLE-UPDATE request primitive to the MS-MLE with the new RA in which the MS-MLE is empowered to 
search for service. 
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Figure 76: Inviting MM intervention - LA outside RA (Scenario 9) 
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1 0.5.9 Set-up of MAC broadcast (SYNC + SYSINFO) (Scenario 1 0) 

The MS-MLE can receive information about its serving cell and its neighbour cells via the SYSINFO 
broadcast and the SYNC broadcast. The decoding of the broadcasts shall be undertaken by the lower 
layers in the MS and should be passed on to the MS-MLE via the survey sub-function (see 
subclause 10.5.7) and the scanning sub-function (see subclause 10.5.2). The SwMI-MLE should provide 
network information to the lower layers for broadcasting by issuing a TL-SYNC request primitive and a 
TL-SYSINFO request primitive. 
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Figure 77: Set-up of MAC broadcast (Scenario 10) 



10.5.10 Set-up of MLE broadcast (NETWORK) (Scenario 11) 



The MS-MLE can receive network information from the SwMI-MLE when attached to a cell. The broadcast 
may contains information about neighbour cells. The broadcast shall be sent in a <D-BROADCAST> PDU 
which is triggered by a a TL-UNITDATA request primitive to the lower layers in the SwMI. The MS-MLE 
should receive the PDU in a a TL-UNITDATA indication primitive. 
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Figure 78: Set-up of MLE broadcast (Scenario 11) 



1 0.5.1 1 MM registering (Scenario 1 2) 

The MM entity may register without being triggered from the MS-MLE. When these procedures are 
applied (see clause 9) and when the MM is satisfied with the registering, the MS-MLE should receive a 
MLE-UPDATE request primitive with the new RA. The MS-MLE shall be empowered to search for service 
in the new RA. 
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Figure 79: MM registering (Scenario 12) 



1 0.5.1 2 Announce old cell and go-to-channel (Scenario 1 3) 



Before announcing the SwMI-MLE, the MS-MLE shall issue a MLE-BREAK indication to the CMCE entity. 

The MS-MLE shall then issue a <U-PREPARE CELL> PDU. This shall inform the SwMI-MLE that the MS 
intends to move to the new cell. The identity of the new cell shall be contained in the 
<U-PREPARE CELL> PDU. On receipt of the <U-PREPARE CELL> PDU, the SwMI-MLE should issue a 
MLE-BREAK indication primitive to the CMCE entity. 

If the SwMI is not able to support the MLE recovery procedure, the SwMI-MLE shall issue a 
<D-PREPARE CELL FAIL> PDU. 

The SwMI MLE should then issue a <D-CHANGE CELL> PDU. This PDU should be transmitted through 
the existing cell and is piggybacked with lower layer information identifying a traffic channel in the next 
cell, e.g. a go-to-channel. After the <D-CHANGE CELL> PDU, no further communications are expected in 
the cell being disused. In the new cell, the configuration of logical channels (e.g. a traffic channel and 
associated control channels) available to the MS should enable the MS to preserve any connections which 
were established prior to the initiation of a cell re-selection. 
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Figure 80: Announce old cell and go-to-channel (Scenario 13) 



1 0.5.1 3 Announce old cell (Scenario 1 4) 



Before announcing the SwMI-MLE, the MS-MLE shall issue a MLE-BREAK indication to the CMCE entity. 

The MS-MLE shall then issue a <U-PREPARE CELL> PDU. This shall inform the SwMI-MLE that the MS 
intends to move to the new cell. The identity of the new cell may or may not be in the 
<U-PREPARE CELL> PDU. On receipt of the <U-PREPARE CELL> PDU, the SwMI-MLE should issue a 
MLE-BREAK indication primitive to the CMCE entity. 

If the SwMI is not able to support the MLE recovery procedure, the SwMI-MLE shall issue a 
<D-PREPARE CELL FAIL> PDU. 

The SwMI MLE should then issue a <D-NEW CELL> PDU in response to the <U-PREPARE CELL> PDU. 
This <D-NEW CELL> PDU shall indicate that the MS may change to the new cell, but does not have 
access to a configuration of logical channels which would enable the MS to continue any ongoing 
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communications. Instead, the MS shall begin communications in the new cell using the common control 
channels. 
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Figure 81: Announce old cell (Scenario 14) 



10.5.14 Announce new cell and successful restoration (Scenario 15) 

The MS-MLE shall send a <U-RESTORE> PDU to the SwMI using the new cell. This shall indicate to the 
SwMI-MLE that the old cell is no longer being used by the MS. All further communications should be 
passed through the new cell. The SwMI-MLE should issue a MLE-RESUME indication primitive to the 
CMCE, indicating that the MLE connection now has been restored and the continuous service is now 
available again. 

The CMCE information may be different in the new cell from that of the previous cell. The CMCE in the 
SwMI may send an SDU to the SwMI-MLE for transmission. The SwMI-MLE should piggyback a 
<D-RESTORE ACKNOWLEDGE> PDU on to the CMCE-generated SDU. If no SDU is received from the 
CMCE, the SwMI-MLE shall still issue a <D-RESTORE ACKNOWLEDGE> PDU. 

On receipt of the <D-RESTORE ACKNOWLEDGE> PDU, the MS-MLE shall issue a MLE-RESUME 
indication to the CMCE entity. 
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Figure 82: Announce new cell and successful restoration (Scenario 15) 
10.5.15 Announce new cell and restoration failure (Scenario 16) 

The MS-MLE shall send a <U-RESTORE> PDU to the SwMI using the new cell. This shall indicate to the 
SwMI-MLE that the old cell is no longer being used by the MS. All further communications should be 
passed through the new cell. 

If the SwMI-MLE is unable to restore the connection to the MS in the new cell, the SwMI-MLE should 
respond to the <U-RESTORE> PDU with a <D-RESTORE FAIL> PDU. After a <D-RESTORE FAIL> PDU 
has been issued, both the MS and SwMI MLEs shall issue a MLE-REOPEN indication primitive to the 
CMCE entity. 
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NOTE: It is now up to the CMCE entity to cater for the restoration of the MLE connection by 
setting up a new one. It is also the responsibility of the CMCE to restore its own 
services. The procedure for this is considered to be outside the scope of this ETS. 
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Figure 83: Announce new cell and restoration failure (Scenario 16) 



10.5.16 Path lost to the serving cell (Scenario 17) 



When the path is lost to the serving cell (e.g. the MAC layer has failed to obtain the SYNC and the 
SYSINFO broadcast for a certain time), the MS-MLE should be informed by a TL-REPORT indication 
primitive. The parameters to the primitive should contain the cause of the path loss. 

If MLE-connection services have been invoked in the MLE by service users, these shall be informed by a 
MLE-BREAK indication. 
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Figure 84: Path lost to the serving cell (Scenario 17) 



10.6 Initial cell selection 



While moving from cell to cell, the MS can use cell re-selection. However, the very first time a MS wants to 
be attached to a cell, i.e. the first time where registration is performed after for instance power up, it shall 
employ the initial cell selection procedures. 

Initial cell selection in the MS-MLE comprises special procedures due to the fact, that both leaving cell and 
LA are unknown. The initial LAs and preferred cells shall be given to the MS-MLE by the MM before 
starting scanning after a suitable cell. The measurement procedures themselves are outside the scope of 
MS-MLE and should be performed by the MAC. Thus the procedures used for initial cell selection may be 
different to the procedures used at cell re-selection. 

When a MS attaches to the SwMI by using initial cell selection, any recovery of MLE connections shall not 
be applicable. Therefore a initial cell selection is only valid for the LMM SAP and other upper layer 3 SAPs 
should in principle be closed for communication. 
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10.6.1 MLE functions as viewed at the LMM SAP 

Until MM starts the scanning process, the MS-MLE should be in a NULL state and not able to 
communicate with anyone. MM should start the selection process by activating the MS-MLE as outlined in 
scenario 3 (see figure 70). 

The MM intervention performed after the activation may be registration and authentication in the new cell. 
If these procedures are successful, the MS shall be attached to the cell. The MM shall inform the MS-MLE 
about the new RA by a MLE-UPDATE request primitive. Finally the MM shall open up the services as 
described in scenario 4 (see figure 71). 

NOTE: The MM intervention may also be another activation of the MS-MLE via a new MLE- 
ACTIVATE request primitive. The parameters may then contain a different set of LAs. 
The initial cell selection procedure should now start all over again. 

10.6.2 MLE functions 

The MS-MLE shall use scanning when initial cell selection is performed. The procedure in scenario 2 (see 
figure 69) may then apply. If a suitable cell can be obtained amongst the scanned cells, the MS-MLE shall 
select this cell (see scenario 3, figure 70). 

If no suitable cell is found, the MM entity may be invited for intervention. However, if the cell is found to be 
suitable for communication, the MM entity should register the MS. 

The initial cell selection shall be completed by opening up the service SAPs towards the MLE service 
users (see scenario 4, figure 71). 

Now the MS-MLE may prepare the monitoring of neighbour cells (see scenario 7, figure 74). 
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End | 



Figure 85: Initial cell selection 
10.7 Cell re-selection by roaming 

After the initial cell selection, further change of cells should be made using cell re-selection procedures. 
While moving within the same network, cell re-selection procedures for roaming shall be applied. The 
network procedures are defined in the MLE. 

When the MS is migrating instead of roaming it simply means that the cell re-selection shall be performed 
choosing a cell in another TETRA infrastructure (SwMI). 

In principle, the procedures described for roaming are also applicable for migration with a few exceptions: 
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MM shall open up a communication path to a new functional entity if MM intervention is required; 

MS shall inform the SwMI about the ceil re-selection. It is assumed that migration shall lead to a 
change in LA. 

10.7.1 Announced cell re-selection 

When a MLE connection has been established, it means that MLE has some responsibilities during cell 
re-selection. These responsibilities are depending on the choice of the type of re-selection procedure. 
There may be three different types of announced cell sub-functions for assistance of this overall 
procedure: 

type-1 ; 
type-2; 
type-3. 

NOTE: A special case exists when the MS does not announce its decision to change cell to 
the old (leaving) cell. It may be due to external events such as loss of signal to the 
serving cell or it may be a controlled way of making cell re-selection. This case is 
known as the unannounced cell re-selection and is described in subclause 10.7.2. 

1 0.7.1 .1 Announced cell re-selection (type-1 ) 
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I End I 

Figure 86: Announced type-1 cell re-selection 
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For the announced type-1 cell re-selection, the MS-MLE shall know the new Traffic Channel (TCH) in 
advance, e.g. before making the decision of changing to the new cell. The cell re-selection may then be 
performed "seamless", where the point of reference for the description "seamless" is the layer 3 service 
boundary. 

The layer 3 service boundary is the sum of all the services offered by MM, CMCE, CONS, S-CLNS. This 
means that at this service boundary, the cell re-selection should not cause any significant interruption of 
services offered by existing MLE connections. 

In order to achieve an announced type-1 cell re-selection, a "go-to-channel" message shall be issued in 
the present serving cell and direct the MS to one or more traffic channels in the new cell. This means that 
the announced type-1 cell re-selection can only be valid for a service user employing the MLE connection 
service. 

10.7.1.1.1 MLE functions as viewed at the LMM SAP 

When MM makes the activation of the MS-MLE, the parameters given by the activation shall be the LAs 
and preferred cells wherein the MS-MLE is empowered to search for service. By the activation, the MM 
should have also informed the MS-MLE of any rules for making the decision to change cell within the RA. 
The MS-MLE is empowered to initiate and perform changes from cell to cell within the RA, which is always 
maintained by the MM. 

If the new cell is found suitable and it is a part of the current RA understood by the MS-MLE, the MM 
should not be involved at all in the cell re-selection procedure. 

NOTE 1 : If MS-MLE does not find a suitable cell, this should be reported to the MM, which then 
should instruct the MS-MLE to search for services in other LAs. The instruction should 
be initiated by a new activation of the MS-MLE (see subclause 10.5.8.1). 

NOTE 2: If MS-MLE finds a suitable cell but it is outside the current RA, the MM should be 
informed. After the MM registering process is finished, the MS-MLE should be 
empowered to continue the cell change (see subclause 10.5.8.2). 

1 0.7.1 .1 .2 MLE functions as viewed at the LCMC SAP 

For announced type-1 cell re-selection to be meaningful to the CMCE service boundary, it is assumed that 
a MLE connection is set-up, i.e. to assist a circuit switched call re-establishment in the U-plane. 

When the MS-MLE identifies a second cell in the same RA, which is preferred due to fulfilment of certain 
network parameters, the MS-MLE shall employ the change-cell-announce procedure described in 
scenario 13 (see figure 80) towards the current serving cell (old cell) and to all service users that have 
established a MLE connection. Once the cell change has been completed and the MLE connections have 
been re-established, the MS-MLE shall make a restore-cell-announce to the new cell according to 
scenario 15 (see figure 82). 

NOTE: Service users that have not set-up a MLE connection in advance are not informed 
about the cell re-selection. However, if a MLE service is invoked during a cell 
re-selection, the service user should be informed about the current condition of the 
MLE - see subclause 10.9. 

If the new cell is found suitable, but the MLE is unable to recover the MLE connection to the new cell, the 
MLE shall re-open the service user SAPs as described in scenario 16 (see figure 83). 

When the LCMC SAP has been re-opened, it shall be the CMCE responsibility to recover the ongoing call 
in the U-plane using CMCE protocol. 

10.7.1.1.3 MLE functions 

Before reaching the point where to decide to start the cell re-selection procedure, the survey scenario 7 
(see figure 74) should have been employed beforehand by the MS-MLE. As output from the surveillance 
process, the MS-MLE should receive path loss measurements and network broadcasts. 
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Also the monitoring process shown in scenario 1 (see figure 68) should be employed by the MS-MLE 
beforehand. A concurrent ranking of neighbour cells shall take place based upon the output from the 
monitoring process. 

When the quality of the serving cell is then deteriorating below a certain threshold, the MS-MLE may start 
the scanning for a new cell employing the scanning scenario 2 (see figure 69) or the MS-MLE may base 
the choice of cell on the current ranking performed by the monitoring process (scenario 1 , see figure 68). 

The cell ranking from the monitoring process and the rules which may have been given to the MS-MLE by 
the MM during a former activation shall be used as parameters to the scanning scenario. 

The path loss for the scanned cell and the network parameters obtained from the SYSINFO broadcast 
and the SYNC broadcast (ETS 300 392-2 [17], clause 23) shall be used as output from the scanning 
process. 

If the new cell is found to be in the same RA and the MS-MLE has approved the quality information 
available for the new cell, the MS-MLE should decide to change to that cell and employ the change-cell- 
announce procedure for the old serving cell as described in scenario 13 (see figure 80). If MS-MLE is 
satisfied with the received information regarding the new cell, the MS-MLE should employ the restore- 
announce in the new cell as outlined in scenario 15 (see figure 82). The result of the restore- 
announcement in the new cell may either be successful or it may fail. 

When the announced cell re-selection type-1 has finished, the MS-MLE should start the monitor 
sub-function in the new cell, as described in scenario 1 (see figure 68). 
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10.7.1.2 



Announced cell re-selection (type-2) 
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End 



Figure 87: Announced type-2 cell re-selection 

The announced type-2 cell re-selection requires only that the MS-MLE knows the new cell in advance. The 
MS does not receive any knowledge of the channel organization on the new cell before making the 
decision to change cell. 

NOTE: The reason to utilize this type-2 announcement may be because the SwMI is not able 
to issue a go-to-channel in the present serving cell, or the network information cannot 
be provided via the present serving cell. 

When employing the announced type-2 cell re-selection procedures, the MLE shall perform the same 
procedures as described in subclause 10.7.1.1.1 except for fact that when the MS-MLE decides to change 
to the new cell, it shall employ the new-cell-announce procedure for the old serving cell (described in 
scenario 14, see figure 81) instead of the change-cell-announce procedure. The restore-cell- 
announcement in the new cell shall be the same as described in subclause 10.7.1 .1 . 

Figure 87 shows the scenarios sequence for the announced type-2 cell re-selection. The shaded 
scenarios are those which are in addition or in another order compared with figure 86 and which 
characterize this type of cell re-selection. 
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10.7.1.3 



Announced cell re-selection (type-3) 
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Figure 88: Announced type-3 cell re-selection 

The announced type-3 cell re-selection implies that the MS-MLE does not know the new cell in 
beforehand, i.e. before MS makes the decision to change cell. The announcement of the old cell is then 
only an information stating that the MS leaves the cell and services may be interrupted for a while. 



10.7.1.3.1 



NILE functions as viewed at the LCMC SAP 



When MS-MLE decides to attempt to change cell based upon the quality information from the serving cell 
and the monitor information from the neighbour cells, new-cell announcement shall be performed in the 
old cell. Once the MS-MLE is satisfied with a new cell, restore-cell announcement shall be performed in 
the new cell. 
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10.7.1.3.2 NILE functions 

The MS-MLE shall check the quality information available for the serving cell and the neighbour cells. This 
quality information should be provided by the lower layers according to scenario 1 and scenario 7 (see 
figure 68 and figure 74). When the MS-MLE decides to change to the new cell, it shall perform the new- 
cell announcement before the scanning scenario 2 (see figure 69) is started. When a suitable cell is 
found, the MS-MLE shall change to the new serving cell according to scenario 6 (see figure 73). 

Invitation of MM by MS-MLE depends on whether the new cell (LA) is within the current RA. If MM 
intervention is needed, MM registering scenario 12 (see figure 79) shall be applied. 

Figure 88 shows the scenario sequence for the announced type-3 cell re-selection. The shaded scenarios 
are those which are in addition or in another order compared with figure 86, and which characterize this 
type of cell re-selection. 

10.7.2 Unannounced cell re-selection 
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Figure 89: Unannounced cell re-selection 

In these scenarios, the MS-MLE shall not inform the present serving cell of the intention to change cell. 
The reason may be that the MS has lost the path or there may be no time to inform the serving cell in 
beforehand. 
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NOTE: It may also be part of normal operation that the MS does not inform its serving cell 
when it decides to change cell. 

The scenario sequence shown in figure 89 is for the unannounced 3 cell re-selection. The shaded 
scenarios are those which are in addition or in another order compared with figure 86, and which 
characterize this cell re-selection function. 

10.7.3 Undeclared cell re-selection 

| Start 
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| End 

Figure 90: Undeclared cell re-selection 

When no MLE connection is present, the MS-MLE shall not have any obligation towards its service users 
and it shall not declare the cell change to neither the serving cell or to the new cell. The MS-MLE is 
empowered to move freely within the RA without contacting the SwMI. 

1 0.7.3.1 MLE functions as viewed at the LMM SAP 

The MM shall be invited to make intervention if the MS-MLE finds that a new cell during the scanning 
scenario 2 (see figure 69) is outside the current RA. The scenario 12 (see figure 79) may then apply 
according to the scenario sequence in figure 90. The shaded scenarios are those which are in addition or 
in another order compared with figure 86, and which characterize this type of cell re-selection. 

10.8 MLE service requests during cell re-selection 

If the MLE service users request service while the MLE is performing cell re-selection, they should be 
informed about the current situation by the MLE. If service is not available, the scenario in figure 91 may 
apply. 
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10.8.1 Undeclared cell re-selection 



The information provided by the MLE informs the service users that service is temporarily not available. 
The information should be provided in a MLE-REPORT indication primitive with the cause = "service not 
available". 

NOTE: The normal case when this information is provided is during undeclared cell 
re-selection; however, the procedure may also be applicable towards service users 
that do not employ MLE connections. 
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Figure 91 : Service requests during undeclared cell re-selection 



1 0.9 No MLE recovery 



It is not a mandatory requirement for the MLE to perform any recovery functions on cell re-selection. 

At the LCMC SAP, the MLE shall issue a MLE-BREAK indication primitive prior to the cell re-selection. 
After the cell re-selection is complete, the MLE shall apply the restore-fail announcement scenario issue a 
MLE-REOPEN indication primitive. 

At the LMM SAP, the MS-MLE shall issue a MLE-LINK indication primitive or a MLE-ACTIVATE indication 
if MM intervention is required. 

10.10 Use of LLC 

The SwMI-MLE can use multiple LLCs simultaneously to provide links to different endpoints. 

The MS-MLE can use multiple LLCs to support concurrent and different kinds of services. 

Each LLC may offer two different types of logical links (basic link and advanced link) between one MS and 
one cell. A basic link and an advanced link shall provide different services to the MLE, which then may 
choose to use either of them based upon the type and the size of the MLE SDU and the quality 
parameters associated. 

1 0.1 0.1 MS-MLE using the LLC basic link 

Whenever a MS has registered and all mobility management activity is finished, the MS shall be attached 
to the SwMI. 

The SAPs towards the MLE service users shall be opened, indicating that the communication path to the 
SwMI is available. 

When a MS is attached to a SwMI the MLE shall have a basic link available from the LLC. This link has 
certain characteristics that the MLE shall recognize and use whenever the MS-MLE service users want to 
communicate with the SwMI. This basic link should be chosen using a set of decision parameters, which 
may be: 

the type of SDUs received on the MLE SAPs; 
the size of the SDUs delivered on the MLE-SAPs; 
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other parameters available. 
10.10.1.1 Basic link and connectionless MLE service 

Figure 92 shows a MS attached to the SwMI and a MLE-UNITDATA is sent to the SwMI using the basic 
link of the LLC. The MLE-UNITDATA may originate from the S-CLNP entity and is examined in the MLE to 
be of limited size. 
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MLE-UNITDATA indication 



MLE Service 
SAP Boundary 



t 



TL-DATA request/confirm 
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SAP Boundary 
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Basic Link' 



Figure 92: MLE utilizing the LLC basic link 



1 0.1 0.1 .2 Basic link and MLE connections 



If a better service is desired from the MLE Service Users point of view, a MLE connection may be 
established. The connection is not a real connection, but simply an association both on the MS side and 
on the SwMI side. Establishing a MLE connection forces the MLE to synchronize the transportation of data 
with MLE controlled functions, such as cell re-selection. 

The connection may be established at any time and removed when no use is required by using 
MLE-CONNECT and MLE-DISCONNECT primitives. The owner of the connection is the MLE service user 
who has established the connection. When establishing a connection, a connection identifier should be 
allocated and associated locally to the MLE. This connection identifier, which is provided to the MLE 
service users, should then be used hereafter whenever data is sent or received on this particularly MLE 
connection. 

Figure 93 shows a MS attached to the SwMI and three MLE connections have been established. These 
connections may have been created by the CMCE. In order to create a MLE connection, MLE-CONNECT 
request shall be sent to the MLE. The connection identifier is returned in the MLE-CONNECT confirm. 
Hereafter only MLE-UNITDATA is necessary to send until MLE-DISCONNECT request is requested in 
order to break the MLE connection. 
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Figure 93: MLE attached and connections established 



1 0.1 0.2 MS-MLE using the LLC advanced link 

If the MLE receives a SDU from the service users that is considered not to be suitable for the LLC basic 
link, the MLE should create an advanced link on the LLC to the SwMI. The decision to deny access to the 
LLC basic link should be taken using the previously defined decision parameters. 

Basically there are 2 reasons to create the advanced link: 

1 ) the grade of service offered from the basic link results in very long transmission time, if packet size 
is too big. The advanced link will provide better grade of service, which will decrease transmission 
time and increase efficiency (throughput); 

2) the load of the air interface, which is a precious resource, is increasing due to the 
acknowledgement scheme associated to the basic link. On the advanced link windowing will utilize 
the air interface in a more efficient way. 

10.10.2.1 Advanced link and connectionless MLE service 

Figure 94 shows a MS attached to the SwMI and a MLE-UNITDATA is sent to the SwMI using the 
advanced link of the LLC. The MLE-UNITDATA may originate from the CONP entity and is examined in 
the MLE to be too big in size. 

Before using the advanced link on the LLC, the MLE shall create it since it is not present by default when 
attachment to the SwMI is performed. This creation shall be done by using TL-CONNECT request/confirm 
primitives. For the very first creation, this primitive can be used for transporting the MLE-UNITDATA PDU 
to the peer entity. 

As long as the MS is attached to the SwMI using the same cell, the advanced link shall be available 
permanently after creation unless a TL-DISCONNECT is used to remove it. A MLE-DISCONNECT issued 
from the MLE service user or an automatically time out mechanism may be applied in order disconnect 
the advanced link. 
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Figure 94: MLE utilizing the LLC advanced link 
Advanced link and MLE connection 



The MLE has also a choice of using the advanced link offered by the LLC based on the decision 
parameters defined previously. 

NOTE: The QoS parameters negotiated at higher layers may also be the reason to choose the 
advanced link if the basic link is not capable of providing the necessary assistance. 

1 1 Technical realisation of SDS 

1 1 .1 Introduction 

This clause specifies the technical realization of the SDS on the network layer of the air interface, i.e. 
specifying: 

an overview of the architectural organization of the network layer, focusing on the short data entity; 

the services provided for the user of the SDS defined as primitives and parameters at the network 
layer SAP; 

the protocol function of the Short Data Protocol (SDP) defined as the encoding of the Protocol Data 
Units (PDU) and the descriptions of the related state machines. 

11.2 General 

The SDS is a message service which shall be optimized to be a quick service enabling the user to 
exchange a short user defined message or a short pre-defined message - e.g. emergency message. The 
message can be sent or received in parallel with an ongoing speech call. 

In order to obtain a fast service, the SDS-message shall be carried or embedded in a single up link 
transmission, e.g. one transfer unit. The SDS shall apply to the random access procedure which implies 
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that the transfer unit shall be equal to half a TDMA slot. However, a double random access may be 
needed if full TSI addressing is chosen. Two half TDMA slots shall then be utilized. 

The service shall comprise point-to-point and point-to-multipoint capabilities and shall have a limited 
number of data bits available for the user, depending on the addressing method used, i.e. Short Number 
Addressing (SNA), full TETRA Subscriber Identity (ITSI/GTSI) and Short Subscriber Identity (SSI) 
addressing. The relation of address method and SDS data length is an optimisation issue only. 

The service shall not provide end to end acknowledgement, but shall use acknowledged services from the 
lower layers in order to obtain a more reliable transmission on a per hop basis. 

Supplementary services defined in the CMCE associated with the SDS may be applied. The services shall 
not be invoked or activated by the SDS entity itself, but in order to be applicable, the services shall be 
invoked or activated in advance by other means. However, some supplementary services, i.e. SNA, 
priority and Area Selection (AS) may be invoked by the short data message itself. 

Within the SwMI, storage capability may also be available. However, the management of the storage is 
beyond the scope of this ETS. 

1 1 .3 Internal organization of the network layer 

The short data protocol entity shall reside on the layer 3 and should be a sub-entity in the circuit mode 
control entity. The service modelling and the network modelling is carried out with respect to this 
relationship throughout this ETS. 



11.3.1 



Service model 



The service model describes the SDS from the perspective of the SDS-SAP as illustrated on figure 95. In 
order to send a short data message, the user shall send a request to the layer 3 SDS. When the request 
has been sent on the first link, a report indication shall be returned to the user with an indication of send- 
success or send-faiiure. At the receiver side, the short data message shall be seen as an indication. 
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Figure 95: Service model for SDS 



11.3.2 



Network model 



The layer 3 SDS entity may be broken down into a number of functional entities, each of them having 
special functional capabilities, in order to transport the message and provide the service for the user. In 
figure 96, the different functional entities are shown. Not all of them can be allocated within a message 
transfer. The ones which are not involved shall be idle. 
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NOTE: The functional entities shown are described in subclause 11.3.2.1. The use of the 
functional entities are described in subclause 1 1 .3.3. 

Figure 96: Network model for SDS 

1 1 .3.2.1 Description of the functional entities 

Each functional entity shall comprise a set of entity specific functions: 

NOTE: Priority is not valid in general for SDS but access priority may be applied. 

Originating Short Data Agent (OSDA) functional entity: 

the OSDA shall be located both in the CMCE-MS and in the CMCE-LS; 

it shall have capability to receive primitives and parameters from the user and send the 
information to the adjacent Originating Short Data (OSD) functional entity in the SwMI; 

the following functional capabilities shall exist within the OSDA: 

ability to send a user defined message limited in length; 

ability to send a pre-defined message, e.g. emergency message; 

ability to address a single point by using ISSI or ITSI address of the message receiver; 

ability to address a multipoint by using GSSI or GTSI of the message receivers; 

ability to address point-to-point or point-to-multipoint by using SDA; 

ability to apply access priority to the message; 

ability to apply 1 of 16 paging areas for the message receiver(s). 
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Destination Short Data Agent (DSDA) functional entity: 

the DSDA shall be located both in the CMCE-MS and in the CMCE-LS; 

it shall have capability to receive information from the adjacent Destination Short Data (DSD) 
functional entity in the SwMI and then forward primitives and parameters to the user; 

the following functional capabilities shall exist within the DSDA: 

ability to receive a user defined message and relay it to the user; 

ability to receive a pre-defined message and relay it to the user, e.g. emergency 
message; 

ability to receive the ISSI or ITSI address of the message sender and relay it to the 
user; 

ability to receive the priority applied to the message, and relay it to the user. 

Originating Short Data (OSD) functional entity: 

the OSD shall be located in the CMCE-SwMI, e.g. in the BS at the message sender side in 
the SwMI; 

it shall have the ability to receive information from the preceding OSDA functional entity in the 
MS or the LS and then forward requests to the subsequent Inter-system Short Data (ISD) 
functional entity or the subsequent Destination Short Data (DSD) functional entity; 

the following specific functional capabilities shall exist within the OSD: 

ability to multiply a received message to different DSDs or ISDs depending on the 
location of the MSs, having the same GSSI or GTSI; 

ability to implement the priority set for the message either by selecting special routes, 
queues or by pre-emption of other messages within the SwMI; 

ability to react on different supplementary services set for the service in advance, such 
as: 

SNA; 
AS; 

Access Priority (AP); 

Barring of Outgoing Calls (BOC); 

List Search Call (LSC). 

- - ability to multiply a received message to different DSDs or ISDs depending on the 
selected paging area. 

NOTE 1 : The OSD is located entirely within the SwMI and further specification and definition is 
beyond the scope of this ETS. 
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DSD functional entity: 

the DSD shall be located in the CMCE-SwMI; 

it shall have the ability to receive information from the preceding OSD functional entity 
in the SwMI or the preceding ISD functional entity in the SwMI and then forward 
requests to the subsequent DSDA functional entity in the MS or in the LS; 

the following specific functional capabilities shall exist within the DSD: 

ability to validate the address of the message receiver, e.g. the SSI or the TSI; 

ability to react on different supplementary services set for the service in advance, such 
as: 

Call Forwarding Unconditional (CFU); 
Call Forwarding No Reply (CFNRy); 

Call Forwarding on mobile subscriber Not Reachable (CFNRc); 

Call Authorised by Dispatcher (CAD); 

Calling Line Identification Presentation (CLIP); 

ability to store the message. 

NOTE 2: The DSD is located entirely within the SwMI and further specification and definition is 
beyond the scope of this standard. 

ISD functional entity: 

the ISD functional entity shall be located in CMCE-ISI, e.g. in the equipment of the ISI in the 
SwMI; 

the functional entity shall exist both at the sending side and at the receiving side; 

it shall have the ability to receive information from the preceding OSD functional entity in the 
same SwMI or the preceding ISD functional entity in another SwMI; 

received information shall be forwarded as requests to the subsequent DSD functional entity 
in the same SwMI or the subsequent ISD functional entity in another SwMI; 

the following specific functional capabilities shall exist within the ISD: 

ability to multiply a received message from a preceding ISD to different DSDs or ISDs 
depending on the location of the MSs, having the same GSSI or GTSI; 

ability to map received messages from a preceding OSD or ISD onto Remote 
Operations Service Element (ROSE) (as defined in CCITT Recommendation 
X.219 [10] and ECMA 165 [15]) via the co-ordination function ECMA 165 [15] at the 
ISI. This mapping shall be done by using the service provided by ROSE; 

Incoming Gateway Short Data (IGSD) functional entity: 

the IGSD functional entity is located in CMCE-IGW, e.g. in the equipment of the gateway in 
the SwMI; 

it shall have the ability to receive information from other non-TETRA networks; 

received information shall be forwarded as requests to the subsequent DSD functional entity 
in the same SwMI or the subsequent ISD functional entity in the same SwMI; 
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the following specific functional capabilities shall exist within the IGSD: 

ability to map the address domain of the gateway network to the TETRA address 
domain. 

Outgoing Gateway Short Data (OGSD) functional entity: 

the OGSD functional entity shall be located in CMCE-OGW, e.g. in the equipment of the 
gateway in the SwMI; 

it shall have the ability to receive information from the preceding OSD functional entity or the 
ISD functional entity in the same SwMI; 

received information shall be sent to other non-TETRA networks forwarded as requests; 

the following specific functional capability shall exist within the OGSD: 

ability to map the TETRA address domain to the address domain of the gateway 
network. 

1 1 .3.2.2 Description of the relationships between functional entities 

Between each functional entity, a functional relationship shall specify the information flow between them. 
The relationships are called n X2 and r2*. 

The n relationship shall specify the access relation between the OSD agent functional entity and the 
AOSD functional entity within the SwMI. It also shall specify the relation between the DSD functional entity 
within the SwMI and the adjacent DSDA. The n relationship shall specify the TETRA air interface protocol 
at the U m reference point (as defined in clause 4). 

The xz relationship shall specify the distributive relation between ASD functional entities within one or 
several SwMls. These are the ISD functional entity, the IGSD functional entity and the OGSD functional 
entity. 

NOTE: Except for the relationship to the ISD functional entity, the xz relationships are beyond 
the scope of this ETS. Thus, these \2 relationships should then only be considered as 
informative. 

The X2 relationship between two ISD functional entities shall specify part of the TETRA Network Protocol 3 
(TNP3 protocol), which is visible at the Q reference point. 

The X2* relationship shall specify the general relation between a gateway SDS functional entity (incoming 
or outgoing) and a non TETRA system, e.g. a PTN, a PSTN or an ISDN. 

11.3.3 Allocation of functional entities 

The functional entities described in subclause 11.3.2.1 may be allocated to different physical locations, 
figure 97 to figure 104 shows different allocations. 

, 1 1 .3.3.1 Point-to-point message transfer within one SwMI 




Figure 97: Point-to-point message transfer within one SwMI 
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1 1 .3.3.2 Point-to-multipoint message transfer within one SwMI 

SwMI 1 




11.3.3.3 



Figure 98: Point-to-multipoint message transfer within one SwMI 
Point-to-point message transfer within two SwMI 
MS SwM1 1 SwMI 2 MS 




Figure 99: Point-to-point message transfer within two SwMI 
1 1 .3.3.4 Point-to-multipoint message transfer within two SwMI 

MS SwMM SwMI2 MS 




Figure 100: Point-to-multipoint message transfer within two SwMI 
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11.3.3.5 



Point-to-point message transfer via an outgoing gateway 
MS SwM1 1 P TN 

r2* 




Figure 101 : Point-to-point message transfer from a SwMI to a PTN, using OGSD 
1 1 .3.3.6 Point-to-point message transfer via an incoming gateway 
MS SwMI 1 PTN 




Figure 102: Point-to-point message transfer from a PTN to a SwMI, using IGSD 
1 1 .3.3.7 Point-to-multipoint message transfer via an outgoing gateway 

MS SwM1 1 

"""" r2* 




PTN 



Figure 103: Point-to-multipoint message transfer from a SwMI to a PTN, using OGSD 
1 1 .3.3.8 Point-to-multipoint message transfer via an incoming gateway 
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Figure 104: Point-to-multipoint message transfer from a PTN to a SwMI, using IGSD 
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1 1 .4 Protocol architecture 



The layer 3 SDS entity should be a sub-entity in the CMCE. The C-plane protocol stacks for the MS and 
the BS are shown on figure 105 and figure 106. 



1 1 .4.1 MS protocol stack 
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CMCE ■ MS 



MLE 



LLC 



LAYER 2 



MAC 



Physical Layer 



LAYER 1 



Figure 105: MS protocol stack 

OSDA functional entity and DSDA functional entity are both located at the top of the Protocol Control (PC) 
within the CMCE-MS. The SDS shall be provided to the user via the TNSDS-SAP at the top of the 
CMCE-MS. The functions of the entities shall be as described in subclause 1 1 .3.2.1 . 



PC contains the state/event machine for the air interface protocol, e.g. it handles short data PDU (as 
defined in ETS 300 392-2 [17], clause 14), and has a peer to peer relationship with the PC within the 
CMCE-SwMI. The PC shall use the normal MLE-primitives to achieve this peer-to-peer relationship. 



MLE, LLC and MAC are entities which are described in clause 6. 
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1 1 .4.2 BS protocol stack 

This subclause contains information residing in the SwMI and as such shall be considered to be outside 
the scope of this ETS and is therefore informative only. The BS architecture is different from the MS 
regarding the SAP to the short data sub-entity. The SAP is a sub-network SAP since it provides service to 
another layer 3 sub layer within the SwMI, e.g. a routing and relaying capability. 
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Figure 106: SwMI protocol stack 

The OSD functional entity and the DSD functional entity are both located at the top of the PC within the 
CMCE-SwMI. The short data sub-entity has relationships to other short data functional entities within the 
SwMI as described in subclause 1 1 .3.2.1. 

PC shall have the same structure as the PC within the MS and LS. 

MLE, LLC and MAC are entities which are described in clause 6. 

11.5 Addressing 

1 1 .5.1 Uplink addressing on the air interface 

The addressing to be used in connection with the SDS on the up link shall either be: 

SSI. When employed, it shall be used both as a destination address and as a source address; or 

TSI. When employed, it shall only be used as a destination address. The source address, i.e. MAC 
address, shall still be the SSI; or 

SNA. When employed, it shall only be used as a destination address. The full address, either the 
SSI or the TSI, should be expanded within the SwMI. The source address, i.e. MAC address, shall 
still be the SSL 
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1 1 .5.2 Downlink addressing on the air interface 

The addressing to be used as a destination address in connection with the SDS on the downlink shall be a 
SSI. 

The addressing to be used as a source address in connection with the SDS on the down link shall be 
either: 

a SSI; or 
a TSI. 

A supplementary service may be invoked to suppress the source address on the downlink. 

1 1 .6 Services provided by the air interface protocol 

The service offered by the short data sub-entity in the CMCE shall be: 

sending and receiving short messages without establishment of a connection over the air interface; 

sending and receiving user defined or pre-defined messages. Only one pre-defined message is 
defined as an emergency message; 

sending messages point-to-point as shown in figure 107 or point-to-multipoint as shown in figure 
108. 

Air Interface Air Interface 

MS SwMI MS 



TNSDS-UNITDATA request 




RR1 : Layer 2 acknowledgement PDU 
U-STATUS, D-STATUS : Layer 3 PDU 



Figure 107: Intra-TETRA (point-to-point) 
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Air Interface Air Interface 




RR1 : Layer 2 acknowledgement PDU 
U-STATUS, D-STATUS : Layer 3 PDU 



Figure 108: Intra-TETRA (point-to-multipoint) 
1 1 .7 Lower layer services used 

The short data functional sub-entities shall use the services of other sub-entities within the CMCE. 
Depending on the location of the CMCE, different lower layers are applied. 

1 1 .7.1 NILE primitives used in the MS and the LS 

The CMCE in the MS and the LS should use the following primitives at the LCMC-SAP in order to provide 
the necessary service to the short data functional sub-entities: 

MLE-UNITDATA request/indication - for providing unconfirmed service in order to transfer the short 
data message; 

MLE-REPORT indication - for providing a report on the transfer of the short data message over the 
air interface. 

12. Technical realisation of TETRA connection mode CONP 
12.1 Introduction 

This clause specifies the technical realisation of the protocol which is intended to provide the connection 
mode (i.e. CONP) service on the network layer of the air interface. This clause describes: 

the protocol services and functions; 

the primitives and sequences for the transmission of data and control information on the air 
interface. 
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1 2.2 Overview of the protocol 

12.2.1 Internal organisation of the network layer and ISO 

The architectural organisation of the network layer is described in clause 6. This protocol shall be used in 
the connection mode where figure 109 gives the layer 3 organisation concerned with CONP. 

Application 
TNCO SAP 



3" 



CONP 



LAYER 3 



LCO SAP 



Mobile 
Link 
Entity 




PD 



TLA SAP Layer 2 Air Interface 

Figure 109: Layer 3 stack on the air interface 

TETRA CONP is based on three ISO standards: 

the network service definition ISO 8348 [12] defining: 

the primitives, actions and events of the service; 

the parameters associated with each primitive action and event; 

the interrelationship and sequences of events and actions; 
the use of X.25 to provide the OSI connection mode network service ISO 8878 [14]: 

proposing CONP primitives; 

mapping between the CONP primitives and the X.25 packets and procedures; 
the X.25 packet layer protocol ISO 8208 [1 1 ] defining: 

procedures for virtual calls and permanent virtual circuits; 
formats and fields of packets associated with these procedures; 
procedures and formats for optional user facilities and DTE facilities. 
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Figure 110: LS protocol stack 



TETRA CONP shall offer services conforming to ISO 8348 [12] with an agreed mapping, to and/or from 
the packet layer protocol elements. This mapping of the connection mode network service shall be based 
on ISO 8878 [14], and the protocol shall be based on ISO 8208 [1 1] (see figure 111). This is described in: 

ETS 300 392-2 [17], clause 24 which is the TETRA delta clause defining the connection mode 
network service at the TNCO SAP, in particular, the service primitives based on ISO 8348 [12] and 
ISO 8878 [14]; 

ETS 300 392-2 [17], clause 25 which is the TETRA delta clause defining the connection mode 
network protocol, in particular, the packets formats and procedures based on ISO 8208 [11]. 
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Figure 111: CONP and ISO 

1 2.2.2 End-to-end protocol 

The ISO references which apply at the SAPs are mandatory or are assumed but not mandatory: 

at the R0 reference point the ISO 8348 [12] (plus delta ETS 300 392-2 [17], clause 24) mandatory 
primitives shall apply; 

at the R2 reference point the ISO 8208 [11] (plus delta ETS 300 392-2 [17], clause 25) mandatory 
protocol shall apply; 
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at the R10 which is a logical reference point equivalent to R0, on the infrastructure, the assumed 
but not mandatory ISO 8348 [12] (plus delta ETS 300 392-2 [17], clause 24) primitives shall apply. 

This protocol is designed to accommodate variability where the underlying protocol can be the MLE, see 
ETS 300 392-2 [17], clause 17, on the MS or BS side or a TETRA specific layer 2 (or Lapb.) on the LS 
side, (see figure 109 and figure 110). 

1 2.3 Handover and mobility 

Mobility implies situations where the mobile changes from one BS to another during a slow handover 
without releasing the established virtual call. Then a set of data, for example state variables, packets 
sequence numbers has to be exchanged by the BS in order to keep the data sequence and avoid 
redundancies or loss of packets. 

1 2.4 Packet through layer 3 in connection mode 

Figure 112 shows the data structure from the application to the layer 2 through CONP and the MLE. 

The user data or message is eventually split into packets and the Packet Header (PH) shall correspond to 
the standard ISO 8208 [11] PH. 
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Figure 112: Data in CONP 

12.5 Interconnection 

Figure 113 to figure 121 position CONP in the protocol stack on the different nodes of the TETRA 
networks. The references points defined in clause 5 are also shown on the figures. 

On figure 1 1 3 there is no direct connection between the two end systems which are the TE, i.e. TETRA 
and MTU2 act as a real sub-network. The MTU2 acts as an inter-working unit. 
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Figure 113: MS to MS through one TETRA network 

Figure 1 14 represents the case of the LS with an example of possible layer 2/1 (LAPB-X.21). 
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Figure 114: LS to MS through one TETRA network 

Figure 115 represents the case of two TETRA networks interconnected through an X.25 or X.75 protocol. 
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Figure 115: MS to MS through two TETRA networks 
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Figure 116 represents the case of two TETRA networks connected through an X.25 PDN using X.25 or 
X.75 protocol. 
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Figure 1 16: MS to MS through two TETRA networks and one X.25 PDN 

Figure 117 represents the case of two TETRA networks connected through an X.25 or X.75 protocol. 
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Figure 1 17: MS to MS through two TETRA networks via one X.25 PDN 

Figure 118 represents MS to DTE through TETRA network and X.25 PDN. 
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Figure 118: MS to standard DTE through one TETRA network and one X.25 PDN 

Figure 119 represents the case of a character mode MS with integrated PAD and character mode LS 
connected via PSTN. 
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Figure 119: Character mode MS with integrated PAD (MTU3) connected to a character mode LS via 

PSTN 



Figure 120 represents a character mode MS with discrete PAD. 
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Figure 120: Character mode MS with discrete PAD 
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Figure 121 represents the connection of the NMU to local and remote TETRA. 
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NOTE: Inter-system inter-working can be either X.75 or X.25 (DTE-DTE ) interconnection. 
Figure 121 : Network management unit connected to a local and a remote TETRA 

12.6 Addresses 

See clause 7. 

1 2.7 Lower layer service used 

CONP shall be capable of operating over: 

a) the MLE, ETS 300 392-2 [17], clause 17, (figure 109) in a MS or BS environment; and 

b) a link layer protocol as shown in figure 1 1 0. 

The service primitives at the LCO SAP are defined in ETS 300 392-2 [17], clause 17. 

In particular the MLE should mask CONP from mobility impacts like re-estabiishment of the link. 

12.8 Services produced by the protocol 

The protocol shall provide the connection mode network service at the TNCO SAP to the upper layer (see 
ISO 8878 [14] and ETS 300 392-2 [17], clause 24). 

The services offered are: 

connection establishment; 

transfer of user data without acknowledgement; 

transfer of user data with acknowledgement; 

disconnection; 

reset; 

expedited data. 
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1 2.9 Primitive definition 

The primitives and sequence of primitives (figure 111) at the TNCO SAP are defined in ETS 300 392-2 
[17], clause 25, these map to the corresponding packets with the fields corresponding to the primitives 
parameters. 

1 2.1 0 Protocol functions 

CONP shall provide the following functions: 

segmentation/assembly of user data into packets; 
PDU composition and decomposition; 
data transfer; 
flow control; 

interrupt transfer allowing to send and receive a small amount of information independent of the 
data stream; 

error control with the ability to detect packet layer errors; 
multiplexing with the ability to support multiple communications; 

reset and restart to reinitialise communication paths in the event that packet layer errors are 
encountered. 

12.11 Structure and encoding of the PDUs 

The PDUs shall be packets with a packet header as defined in ETS 300 392-2 [17], clause 25, with the 
following types: 

call set-up and call clearing packets; 

data and interrupt packets; 

flow control packets; 

reset packets; 

restart packets. 

The packet header shall contain at least the standard following information: 
general format identifier; 
logical channel identifier; 
packet type identifier; 

additional fields like sequence numbers, user data see ISO 8208 [11]. 
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13 Technical realisation of TETRA specific connectionless S-CLNS 

13.1 Introduction 

This clause specifies the technical realisation of the protocol which is intended to provide the specific 
connectionless mode service on the network layer of the air interface: 

the protocol functions; 

primitives and sequences for the specific connectionless transmission of data and control 
information on the air interface; 

the PDUs list for the transmission of data and control information. 

1 3.2 Overview of the protocol 

1 3.2.1 Internal organisation of the network layer 

The architectural organisation of the network layer is described in clause 6. This protocol shall be used in 
the access protocol role (SNACP) as described in the ISO 8473 [13]. Figure 122 gives the layer 3 
organisation concerned with SCLNS where the MLE is the Mobile Link Entity (or network link entity), see 
ETS 300 392-2 [17], clause 1 7. 
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Figure 122: Layer 3 S-CLNP protocol stack on the air interface 

This protocol shall be designed to accommodate variability where the underlying protocol can be the MLE 
on the MS (figure 122) or a sub-network dependant sub-layer (SNDCP) for convergence as described in 
figure 123. It shall also offer services to support a user application implementation of CLNP (figure 123). 
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Figure 123: LS (LS) protocol stack 

In order to optimise the protocol two versions are created: 

a full version with the TETRA specific facilities; 

a version without any facilities called the slim version. 
1 3.2.2 Interconnection 

Figure 124 to figure 129 position the S-CLNP in the protocol stack on the different nodes of the TETRA 
networks. The reference points are also shown on the figures. 

Figure 124 gives the MS to MS interconnection through a TETRA network. 
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Figure 124: MS to MS through one TETRA network 
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Figure 125 gives the LS connection where different possibilities are offered as the layer 2 and layer 1 can 
be TETRA specific or existing standards (figure 122) where: 



case 1 : 



case 2: 



S-CLNP accesses through a CONP access protocol with the SNDCP 
convergence asking for a virtual circuit to be established in the connection mode 
(see table 3); 

direct access of S-CLNP to layer 2 which can be in that case a specific TETRA 
layer 2 (see table 3). 

Table 3: Standard possibilities for layer 1 and layer 2 
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Figure 125: LS to MS through one TETRA network 

Figure 126 shows the interconnection of two TETRA networks where TETRA1 adds a X.75 header to the 
specific connectionless packet and sends it via an X.25 protocol to the network in a connection mode. 
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Figure 126: MS to MS through two TETRA networks 

Figure 127 shows the case of two TETRA networks interconnected through a CLPDN. 
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Figure 127: MS to MS through two TETRA networks and one CLPDN 
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Figure 128 is the case of an intermediate X.25 PDN where the specific connectionless packet is put in an 
X.25 packet on a virtual circuit. 
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Figure 128: MS to MS through two TETRA networks via one X.25 PDN 



Figure 129 shows the case of a MS sending and receiving data from an application on a host <DTE> 
through an X.25 PDN. The SCLNS is built on a CONS protocol where the specific connectionless packet 
is sent in a X.25 packet over a virtual circuit. 



Page 132 

ETS 300 392-1: February 1996 



DTE 



MS 



TETRA 1 



MTU2 



TE2 




DTE - DCE 



TETRA 1 
infrastructure 


SCLNP (fwd 


2) 


X.25 




mle 


(LAP-B) 




AI2 


(X.21) 




Al 1 



□ 

R6 



□ 



SCLNP (fwd 1) 


mle 




AI2 


(LAP-B) 


Al 1 


(X.21) 



App. 



SCLNP 



(LAP-B) 



(X.21) 



R2 



□ 
R1 



Figure 129: MS to standard DTE through one TETRA network and one X.25 PDN 
13.3.3 Addresses 

The source address and destination address shall be TETRA addresses described in clause 7. 

Two length of addresses shall be allowed: 3 octets (SSI) or 6 octets (TSI) named short and long 
addresses which allow reducing the header length inside PDUs. 

1 3.3 Lower layer service used 

It is intended that SCLNS shall be capable of operating over: 

a) the MLE (figure 122) in a MS or BS environment; or 

b) an sub-network dependent sub-layer protocol. 
The access point shall be the LSCL-SAP. 

The MLE offers services for the establishment and release of a layer 2 connection which may be used by 
the S-CLNP entity. 

The service primitives shall be: 

MLE-CLOSE indication to indicate that access to the MM link has been removed; 

MLE-OPEN indication to inform that access to the link is available; 

MLE-UNITDATA request to send control data; 

MLE-UNITDATA indication to indicate the arrival of control data; 

MLE-UNITDATA confirm for confirmation; 

MLE-BREAK indication to inform that the current link is no longer available. 

The underlying protocol on a LS shall be either a sub-network dependant sub-layer which ensures 
convergence to CONP or directly layer 2, (see figure 123). 
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13.4 Services provided by the protocol 

The protocol shall provide the S-CLNS at the SCLNS SAP to the user application. 

Two services shall offer the full version with the TETRA specific facilities and the slim version without the 
facilities. 

NOTE: The ISO CLNP is intended to be carried by the slim version. 

13.4.1 Full version 
The services offered shall be: 

send and receive user data without connection establishment; 

confirmation of uplink success to transfer data. 

This service allows the sender of uplink data to know that his data has reached the infrastructure, by 
means of a confirmation report i.e. the delivery report. 

This service informs the sender that his data has been delivered to the remote destination. 

13.4.2 Slim version 

The services offered shall send and receive user data without connection establishment as for the full 
version. 

13.5 Primitives definition 

The set of primitives to offer the services described concerns the data transmission (see ETS 300 392-2 
[17], clauses 26 and 27. 

1 3.5.1 Data transmission group 

The request and indication primitives at the S-CLNP SAP for data transmission shall be: 

TN-U N ITD ATA request (parameters) ; 

TN-UNITDATA indication (parameters). 
The parameters are described in ETS 300 392-2 [1 7], clause 27. 
These primitives are common to full and slim versions to send and receive data. 

Confirmation of the uplink success (or failure) to transfer the data to the infrastructure, (a local 
infrastructure immediate answer) shall be reported by: 

TN-UNITDATA confirm (parameters). 
The parameters are described in ETS 300 392-2 [17], clause 27. 
Delivery of the user data shall be reported by: 

TN-DELIVERY indication ( parameters). 
The parameters are described in ETS 300 392-2 [1 7], clause 27. 

13.5.2 Protocol sequences 

Figure 130 shows the layer 3 protocol sequence on the MS side. 

Figure 131 shows the protocol sequence at layer 3 MS to BS for point-to-point with delivery disposition. 
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Figure 132 is the multipoint case with delivery disposition. 
Figure 133 shows the inter TETRA case. 

SPECIFIC CONNECTIONLESS 
MS BS 



TN-UNITDATA request 



TN-UNITDATA confirm 
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Figure 130: Network layer service primitives sequences specific connectionless at TNSCLNS SAP 
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Figure 131: Point-to-point SCLNS 
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Figure 132: Multipoint case 
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Figure 133: Inter-TETRA case 



Figure 134, figure 135 and figure 136 detail a scenario involving confirmation of successful transfer to the 
infrastructure by a TN-UNITDATA confirm, a status transfer within a layer 2 acknowledge after this status 
has been pre-set, and a delivery indication to the sender. 

In the report indication scenario (figure 135) the layer 2 acknowledge sent by the infrastructure and 
associated with the successful uplink transfer of data shall correspond to a TL-DATA confirm primitive at 
the MS MLE boundary which shall become a TN-UNITDATA confirm at the MS application boundary. 

In the delivery indication scenario with status, a status shall be set by a TN-SETSTATUS request. The 
uplink data shall be acknowledged at layer 2 by the remote entity (MS) and the ACK shall carry the status 
message read in the LLME. The network layer 2 shall issue a primitive TL-DATA confirm becoming a 
MLE-UNITDATA confirm at the S-CLNP boundary. Assuming the delivery confirmation has been set the 
network shall build an S DEL PDU which is sent back to the MS including the status. 
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1 ) TN-UNITDATA request (send data); 

2) MLE-UNITDATA request; 

3) TL-DATA request; 

4) TL-DATA confirm (confirm of transfer to infrastructure); 

5) MLE-UNITDATA confirm; 

6) TN-UNITDATA confirm; 

7) TL-DATA indication; 

8) MLE-UNITDATA indication; 

9) MLE-UNITDATA request; 

10) TL-DATA request; 

1 1 ) TL-DATA indication; 

12) MLE-UNITDATA indication; 

1 3) TN-UNITDATA indication (data delivered to application); 

14) TL-DATA confirm; 

1 5) MLE-UNITDATA confirm; 

1 6) MLE-UNITDATA request; 

17) TL-DATA request; 

1 8) TL-DATA indication; 

19) MLE-UNITDATA indication; 

20) TN-DELIVERY indication. 



Figure 134: End-to-end scenario, involving confirmation and delivery confirmation 



Page 137 

ETS 300 392-1 : February 1996 



mobile station 



app. ( sclnp 
TN-UNITDAtA request 



mle 



^1 
TN-UNITDATA confirm 



. TL-DATA request 
MLEjUNITDATA r<Jquest^-^ 

< 

ML^-UNITDATA tponfirrn^ ^ 

£r^\ TL-DATA confirm 

I 



L2 



-> Primitive 



network 



<U data> 
<ack> . 



12 



mle 



sclnp 



TNl-UNITDATA indication 



app. 



Message 



Figure 135: Report indication scenario 
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Figure 136: Delivery indication scenario 

1 3.6 Protocol functions 



The S-CLNP may provide different functions depending where it is located, i.e. on a send system type, or 
a forward or a receive system type. The forward system type is on the MTU or on the infrastructure, (see 
ETS 300 392-2 [17], clause 27). 



The functions shall be: 



PDU composition/decomposition; 
routing/forwarding/discarding of PDU; 
error reporting; 
facility handling. 
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13.7 Structure and encoding of the PDUs 

To optimise the size of the packet header several options shall be offered: 
short or long addressing; 

a slim PDU which contains no facilities field compared to the full version. 

Different PDUs are defined for each interface. On the air interface the uplink PDU can be different from 
the same type downlink PDU. 

The structure and encoding of the PDUs are described in ETS 300 392-2 [17], clause 27. Figures 131, 
132 and 133 show the types of PDUs on the uplink and downlink. 

The different types of PDUs shall be S1 meaning uplink, S2 meaning downlink and S3 meaning ISI: 

S1_DT_PDU Uplink data PDU; 

S2_DT_PDU Downlink data PDU; 

S3_DT_PDU which is the inter-TETRA data only PDU; 

S2_DEL _PDU which is the downlink delivery PDU; 

S3_DEL_PDU which is the inter-TETRA delivery PDU. 
14 General on supplementary services 

14.1 Introduction 

The purpose of this clause is to define a recommended set of supplementary services to the teleservices 
and bearer services which should be supported by a TETRA network in connection with other networks as 
a basis for the definition of the network capabilities required. Further it recommends a strategy for the 
description of supplementary services. 

NOTE: The abbreviation SS is only used when referring to a specific supplementary service. 

14.2 General 

1 4.2.1 Framework for the description of supplementary services 

ETR 086 [16] describes the principles of the telecommunication services provided in a TETRA 
network. It defines the concepts of telecommunication services and describes their characterization 
by appropriate attributes. Bearer services and teleservices, which are offered by a TETRA network in 
connection with other networks, are also defined in ETR 086 [16]. 

A supplementary service modifies or enhances a basic bearer service or teleservice or other 
supplementary service. The same supplementary service may be offered with a number of different 
telecommunication services. 

Table 4 illustrates the description of telecommunication services. 



Table 4: Categorisation of telecommunication services 



Telecommunication service 


Bearer service 


Teleservice 


Basic Bearer Service 


Basic bearer Service + 
Supplementary service 


Basic Teleservice 


Basic Teleservice + 
Supplementary service 
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In accordance with CCITT Recommendation 1.130 [5], the following three level structure is used to 
describe the supplementary telecommunications services as provided by European TETRA 
Operators: 

Stage 1 : is an overall service description, from the user's stand-point; 

Stage 2: identifies the functional capabilities and information flows needed to support the service 
described in stage 1 ; 

Stage 3: defines the signalling system protocols and switching functions needed to implement the 
sen/ice described in stage 1 . 

1 4.2.2 Alignment with the European Computer Manufacturers Association (ECMA) 

Stage 1 , stage 2 and stage 3 descriptions of the TETRA supplementary services shall align with the 
appropriate corresponding ECMA standard. Deviations from these standards, which are applicable to 
TETRA networks, shall be recorded as Deltas. In so doing a harmonised and speedy implementation of 
many TETRA supplementary services may be realised. 

Where no ECMA standards exist, then new descriptions shall be devised, following the principles laid 
out in the ECMA documentation. 

14.2.3 Methodology 

The purpose of stage 1 and 2 specifications is to guide and constrain the work on signalling protocols 
at stage 3. 

Stage 1 is a general description of the overall functioning of the service. 
Stage 2 consists of the following steps: 

Step 1 : functional model identification of functional entities and their relationship; 

Step 2: information flow diagrams; 

Step 3: SDL diagrams for each functional entity; 

Step 4: functional entity actions; 

Step 5: allocation of functional entities to physical locations. 

The decision to follow ECMA's stage 2 is an important one and is based on considerations of 
signalling across the ISI. In the case of inter-working, unless it is clearly understood where functional 
entities reside, then there is no means of understanding the signalling protocols across the ISI. 

Steps 1, 4 and 5 of stage 2 identify functional entities within the infrastructure, allocate them to 
physical locations within it, and examine their behaviour. It is appreciated that, depending on the 
equipment manufacturer and service application, there may be many different combinations possible 
to locate functional entities. 

The specific combination of functional entities may determine the type and content of messages 
across the ISI. 

The protocol design at stage 3 can now be understood. Different allocations of functional entities to 
physical locations may produce different protocols and procedures across the ISI. 

The stage one descriptions of the different supplementary services are contained in ETS 300 392-10 
[18]. 
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1 4.3 Supplementary service concepts 

A supplementary service modifies or supplements a basic bearer service or teleservice or other 
supplementary services. 

14.3.1 Concepts associated with supplementary services 

The terms used in the stage 1 descriptions are defined in the following subclauses. 

14.3.1.1 Provision 

An action to make a service available to a user. The provision may be: 

general: where the service is made available to all users (subject to compatibility restrictions 
enforced) without prior arrangements being made with the service provider; 

pre-arranged: where the service is made available to an individual user only after the necessary 
arrangements have been made with the service provider. 

14.3.1.2 Withdrawal 

An action taken by the service provider to remove an available service from a user's access. The 
withdrawal may be: 

general: where the service is removed from all users provided with the service; 

specific: where the service is removed on an individual basis from users provided with the service; 

temporary: where the service is removed for a period of time and may be provided later without 
further arrangements. 

14.3.1.3 Activation 

An action taken by either the service provider or the served/authorized user to enable a process to 
run, as and when required, by the service concerned. The time during which the process is activated 
is defined as the active phase. During activation the sen/ice shall be either "operative" or "not 
operative" according to whether or not the system is actually using the service, e.g. to forward a call 
or to apply call waiting indication. 

1 4.3.1 .4 Deactivation 

An action taken by either the service provider or the served/authorized user to terminate the process 
started at the activation. A supplementary service can be automatically deactivated at the end of a 
call if the supplementary service was specifically activated for that call. Additionally, a supplementary 
sen/ice may be automatically deactivated by the network as a consequence of activation of another 
supplementary service if it conflicts with the other activated supplementary service. 

14.3.1.5 Definition 

An action taken by either the sen/ice provider or the served/authorized user in order to define or 
redefine parameters relating to a particular supplementary sen/ice, (e.g. redefine short numbers 
within SS-SNA, or defining personalised areas in a network within SS-AS). 

14.3.1.6 Registration 

The programming by the service provider to identify certain authorized users, who may be allowed to 
activate/deactivate/invoke/define/cancel/interrogate a certain supplementary sen/ice. 
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14.3.1.7 Interrogation 

An action taken by the served/authorized user in order that useful information regarding a particular 
supplementary sen/ice may be obtained, e.g. to ascertain the activity state and parameters of a given 
supplementary service. 

A general interrogation of all supplementary services may be provided. 
EXAMPLE: possible interrogation and testing processes. 

The following interrogation and testing processes are identified here for possible use: 
status check: the following values can be returned by the infrastructure: 

not supported; 

not subscribed to; 

activated; 

deactivated. 

Not all values are applicable to supplementary services. 

data check: this interrogation function compares the data input by the user during an interrogation 
procedure with the information stored in the infrastructure. The infrastructure signals an appropriate 
indication e.g. "check is positive" or "check is negative"; 

data request: this interrogation function enables the user to obtain confirmation of his input data. 
The infrastructure signals an appropriate indication; 

testing: this test procedure allows the user to check whether or not the service is operating as the 
user desires. In some cases the use of the service is sufficient, for others a method of testing is 
included in the control procedure. 

14.3.1.8 Cancellation 

An action taken by the served/authorized user in order to stop an invoked supplementary service 
from continuing with its procedures. 

14.3.1.9 Invocation 

An action to invoke the service required, taken by the user (e.g. pressing a specific button) or 
automatically by the network or terminal as a result of a particular condition (e.g. calling number 
identification for each incoming call). 

14.3.1.10 Operation 

Description of the normal operation of the service, the user's actions and the system response. 
Decision points, timing and call progress signals should be some of the aspects described for the 
sen/ice if they can be perceived by the users. 

1 4.3.1 .1 1 Exceptional procedures 

Abnormal situations which are not described in subclauses 14.3.1.1 to 14.3.1.10 shall be identified, 
the causes given and the responses expected. Procedures on time-out, unexpected signalling 
response and other such events should be defined. 

1 4.3.1 .1 2 Inter-working considerations 

Identification of user perceptions when a call exits from a TETRA network to another TETRA. 
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1 4.3.2 Supplementary service invocation order 

Before offering an incoming call to the called user, or before allowing an outgoing call from a calling user 
to be completed, the infrastructure should search through the user supplementary service database for 
the activation of supplementary services and proceed with their invocation in the following order: 
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14.3.3 Use of a password option in relation to supplementary services 

Some supplementary services (e.g. call barring) may be offered to a user with the subscription option 
of using a password to control the service. When this option is selected every action (related to that 
supplementary service), such as registration, activation or deactivation should be performed by the 
mobile user with the concurrent entry of the password. 



14.3.3.1 Description 

When the subscription option "control of a supplementary service by the user using a password" is 
provided, password handling shall be supported by the network. 



14.3.3.2 Management - normal procedures 
1 4.3.3.2.1 Provision of password option 

Each supplementary service for which the control by the usage of a password is relevant may be 
offered with the subscription option "control of the supplementary service". The values of this option 
may be: 



by the user using a password; 



by the service provider. 



A service provider need not offer this option to its users. 
1 4.3.3.2.2 Withdrawal of the password option 

The password option may be withdrawn for administrative reasons or due to subscription 
modification. 



1 4.3.3.2.3 Registration of password 

If a mobile user selects at provision time the option of using a password for any given supplementary 
service, the password shall be registered at the same time. 

Furthermore, the user should be able to change the password by an appropriate control procedure at 
any time. 
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1 4.3.3.2.4 Erasure of password 

A password may be erased in two ways: 

1) registration of a new password erases the previous one; or 

2) withdrawal of the password option. 

1 4.3.3.2.5 Password checking 

If the mobile user, in an attempt to control a supplementary service requiring a password, enters a 
correct password, the corresponding request shall then be considered by the network. 

1 4.3.3.3 Management - exceptional procedures 

If the mobile user, in an attempt to control a supplementary service requiring a password or in an 
attempt to register a new password, enters an incorrect password, the corresponding request should 
be rejected by the network and the user should be notified. 

If the mobile user enters incorrect password more than possibly three consecutive times, all control 
procedures related to the use of the password should be made impossible until the service provider 
instructs the network to again accept password-related requests from the user. 

1 4.4 Supported supplementary services 

Table 5 gives a list of the supplementary services standardized in TETRA, the service definitions of 
which are given in ETS 300 392-10 [18]. 

NOTE: All supplementary services identified within this table are defined for calls within a 
TETRA system or between two TETRA systems which support the supplementary 
service. 

Table 5 lists the categories for all supported supplementary services. The following list shows the 
abbreviations used. 

Provision: 

g = generally available; 

p = pre-arrangement (subscription basis). 

Withdrawal: 

u = user's request or for administrative reasons; 

- = not applicable. 

Activation: 

p = as a result of provision; 
r = as a result of registration; 
d = as a result of definition; 
u = user controlled procedure; 

c = when the conditions in the subscription options are met; 

- = not applicable. 

Deactivation: 

w = as a result of withdrawal; 
u = user controlled procedure; 

n = when the conditions in the subscription, options are not met; 

- = not applicable. 

Definition: 

u = user controlled procedure; 

a - service provider controlled procedure; 

- = not applicable. 
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Registration: 

p = as a result of provision; 

a = service provider controlled procedure; 

u = user controlled procedure; 

- = not applicable. 

Interrogation: 

u = user controlled procedure; 

- = not applicable. 

Cancellation: 

u = user controlled procedure; 

- = not applicable. 

Invocation: 

n = automatic invocation by the network as a result of a particular condition; 
u = user invocation, by means of a control procedure; 

- = not applicable. 
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Table 5: Supported supplementary services 
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NOTE: The individual abbreviations for the supplementary services are not repeated here but given 
in clause 3. 
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1 4.4.1 Format of description 

The supplementary services shall be described according to the following format: 
Supplementary services stage 1 

a) service within TETRA: 

definition; 
description; 
general description; 

qualifications on applicability to telecommunication services; 

procedures; 

provision/withdrawal; 

normal procedures; 

exceptional procedures; 

interaction with other supplementary services; 

b) inter-working considerations; 

c) overall SDL; 
Supplementary service stage 2 

d) functional model: 

functional model description; 
description of functional entities; 

e) information flows; 

f) functional entity actions; 

g) functional entity behaviour; 

h) relationship to basic call and mapping onto physical equipment; 
j) inter-working considerations; 

Supplementary service stage 3 

k) coding requirements; 

I) signalling protocol. 
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Annex A (informative): Individual circuit mode call scenarios 



A.1 Introduction 

This annex show the typical scenarios and time-sequence diagrams for individual calls. The annex is split 
into three parts dealing with message trunked procedures (see clause A.2), transmission trunked 
procedures (see clause A.3) and quasi transmission trunked procedures (see clause A.4). 



A.2 Procedures - message trunked systems 
A.2.1 Call set-up - on/off hook signalling 



Figure A.1 refers. The call set-up request can be started by an up-link message <U-SETUP> from the MS. 
The SwMI may acknowledge the call set-up request by sending a down-link message 
<D-CALL PROCEEDING> and to indicate that the call is being processed. 



Traffic 
channel 
3 1 location 

MS A Air Interface SwMI Air Interface MS B 




NOTE 1 : The indication of of/off hook signalling is indicated in the D-SETUP message. 

NOTE 2: Early assignment, i.e. the traffic channel is allocated at earliest possible point. 

NOTE 3: Medium assignment, i.e. the traffic channel is allocated when the called mobiles 
presence is established. 

NOTE 4: Late assignment, i.e. the traffic channel is allocated when the called user has 
answered. 

NOTE 5: Example of other signalling. 

Figure A.1 : Call set-up, on/off hook signalling, message trunked system 

If following the receipt of a <U-SETUP> message, the SwMI determines that for some reason the call 
cannot be supported, or if it is indicated to the SwMI that the call cannot be supported by the called user, 
then the SwMI should initiate call clearing as defined in subclause A.2.9. 
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If the call can be supported, the SwMI should send a down-link message <D-SETUP> to the called MS to 
start the alerting process at the called mobile. It should be indicated to the called MS that on/off hook 
signalling is being used for this call. This message may be acknowledged by a <U-ALERT> to indicate 
that the called mobile has begun the alerting process. 

Upon receiving an indication that the called party is alerting (<U-ALERT>), the SwMI should send a 
<D-ALERT> to the calling party. 

When the called MS answers, a <U-CONNECT> message should be sent from the called MS to the 
SwMI. 

Upon receipt of the <U-CONNECT> message the SwMI should send a <D-CONNECT> message to the 
calling MS and a <D-CONNECT ACKNOWLEDGE> to the called MS. 

Communication can commence. 

NOTE: As an implementation option the network may support other signalling from the calling 
MS to the SwMI and visa versa during the call set-up phase, for the purposes of 
supplementary services et al. Similarly the network may support signalling to the called 
MS at this time. 

A.2.1 .1 Traffic channel assignment 

There may be three methods for assigning a traffic channel: 

1) early assignment the traffic channels can be assigned and indicated to the calling and called MS 
along with the <D-CALL PROCEEDING> and <D-SET-UP> messages respectively, (contained in 
the lower layer part of those messages). In this case the calling MS should move immediately to the 
traffic channel in anticipation of the call and should receive all call control messages on this 
channel; 

2) medium assignment the traffic channels can be assigned and indicated to the calling MS along 
with (in the lower layers) the <D-ALERT> message, and indicated to the called MS in a layer 2 
acknowledgement to the called MS <U-ALERT> message. In this case the calling MS should move 
to the traffic channel in anticipation of the call and should receive all call control messages on this 
channel; 

3) late assignment the traffic channels cannot be assigned until the called MS sends a 
<U-CONNECT> message. Upon receipt of this message the traffic channels can be indicated to the 
calling and called MS along with the <D-CONNECT> and <D-CONNECT ACKNOWLEDGE> 
messages respectively, (contained in the lower layer part of those messages). In this case the 
calling MS should remain listening on the control channel until he is told to move to the traffic 
channel. 

A.2.2 Call set-up - direct set-up signalling 

Figure A.1 refers. The call set-up request can be started by an up-link message <U-SETUP> from the MS. 
The SwMI may acknowledge the call set-up request by sending a down-link message 
<D-CALL PROCEEDING> and to indicate that the call is being processed. 

If following the receipt of a <U-SETUP> message, the SwMI determines that for some reason the call 
cannot be supported, then the SwMI should initiate call clearing as defined in subclause 2.9. 

If the call can be supported, the SwMI should send a down-link message <D-SETUP> to the called MS 
and it should be indicated to the called MS that direct set-up signalling is being used. This message 
should be acknowledged by a <U-CONNECT> to indicate that the called mobile is able to receive the call. 
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NOTE 1 : The request to send direct signalling is indicated in the D-SETUP message. 

NOTE 2: Early assignment, i.e. the traffic channel is allocated at the earliest possible point. 

NOTE 3: Late assignment, i.e. the traffic channel is allocated when the called user has 
answered. 

Figure A.2: Call set-up, direct set-up signalling, message trunked system 

Upon receipt of the <U-CONNECT> message the SwMI should send a <D-CONNECT> message to the 
calling MS and a <D-CONNECT ACKNOWLEDGE> to the called MS. 

Communication can commence. 

A.2.2.1 Traffic channel assignment 

There can be two methods for assigning a traffic channel: 

1) early assignment the traffic channels can be assigned and indicated to the calling and called MS 
along with the <D-CALL PROCEEDING> and <D-SET-UP> messages respectively, (contained in 
the lower layer part of those messages). In this case the calling MS should move immediately to the 
traffic channel in anticipation of the call and should receive all call control messages on this 
channel; 

2) late assignment the traffic channels cannot be assigned until the called MS sends a 
<U-CONNECT> message. Upon receipt of this message the traffic channels should be indicated to 
the calling and called MS along with the <D-CONNECT> and <D-CONNECT ACKNOWLEDGE> 
messages respectively, (contained in the lower layer part of those messages). In this case the 
calling MS should remain listening on the control channel until he is told to move to the traffic 
channel. 
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A.2.3 Request-totransmit 

The SwMI should be in full control over which MS is allowed to transmit because the MS should request 
permission to transmit, and permission should be granted before the MS can do so. 

Traffic 

MSA Air Interface SwMI Air Interlace MSB channel 
. , , , , allocation 




Figure A.3: Request to transmit, direct or on/off hook signalling, message trunked system 

If on/off hook signalling is used, it should be normal system operation that the called MS is given 
permission to transmit by default in the <D-SET-UP> message and early, medium or late assignment 
should apply as appropriate. However, if desired, the calling MS can ask for permission to transmit in the 
<U-SETUP> message. The response to this request is dealt with in subclause A.2.4, case (1). 

If direct set-up signalling is used, it should be normal system operation that the calling MS should given 
the permission to transmit immediately upon call set-up. Traffic channel assignment should be as 
previously discussed in subclause A.2.2.1 . 

For both signalling methods, when the awarded mobile has finished the communication it should send a 
<U-TX CEASED>. Figure A.3 refers. 

Upon receipt of the <U-TX CEASED> message, the SwMI should send a <D-INFO> message to the 
"receiving" MS to inform him that the transmission from the other MS has now ceased. The SwMI should 
await further demands from the calling and called MS's. When either MS wishes to make a request to 
transmit, it should send a <U-TX DEMAND> message. The response to this request is dealt with in 
subclause A.2.4, case (2). 
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A.2.4 Response to request-to-transmit 

Case 1 : if on/off hook signalling applies and the calling MS has asked for permission to transmit at the call 
set-up, the SwMI can award permission as appropriate and should respond to this request in the 
<D-CALL PROCEEDING> message. If permission is granted, then the SwMI should also inform the called 
MS in the <D-SET-UP> message that permission has not been granted to him. 

Case 2: figure A.3 refers. During any call, a <U-TX DEMAND> message may be sent by either MS. If the 
other MS is not already transmitting then the SwMI response should be a <D-TX GRANTED> message 
sent to the awarded MS, and a D-INFO sent to the other MS. 

If a <U-TX DEMAND> message is sent and the other MS is already transmitting, then the SwMI should 
wait for that party to finish the transmission, (identified by the receipt of a <U-TX CEASED> message). 
Subsequently the SwMI should send a <D-TX GRANTED> message to the awarded MS and a D-INFO to 
the other MS. Priority requests are dealt with under subclause A.2.8. 

A.2.5 Permission to transmit withdrawn 

The SwMI may decide to interrupt transmission when resources are required for another call or that the 
SwMI requires that the call should temporarily pause. In this case the SwMI should send a <D-TX WAIT> 
message to both mobiles. Permission to transmit should be withdrawn, or should not be given to a 
requesting mobile. The MSs should obey channel allocation and await further instructions on the channel 
that they have been directed to. The <D-TX WAIT> should: 

confirm to the MSs that the call is in a queue; 

indicate to the MSs that they should not send further requests-to-transmit. 

If the request-to-transmit is granted but queued, the MS may be allowed to withdraw its 
request-to-transmit by means of the message <U-TX CEASED>. 

A.2.6 Permission to continue with withdrawn call 

When the SwMI has decided that the call can continue, the SwMI may send a <D-TX GRANTED> 
message to the awarded mobile and a <D-TX CONTINUE> message to the other mobile and the mobiles 
may be told to go to the traffic channel. If no mobiles have been given permission to transmit then they 
should be sent a <D-TX CONTINUE> message and are free to make a request to the SwMI. 

A.2.7 End of transmission 

At the end of a communication, the MS should send <U-TX CEASED> and listen to the traffic channel. 
Figure A.3 refers. The SwMI should send a <D-INFO> to the other participant. 

A.2.8 Stop-transmission order 

Figure A.3 refers. If, during the course of a transmission, a MS wishes to interrupt the transmitting MS with 
a higher priority request, a <U-TX DEMAND> message should be sent indicating the level of priority, the 
SwMI should send a <D-INTERRUPT> message to the transmitting MS and a <D-TX GRANTED> 
message to the requesting MS. Both messages should indicate the permission to transmit has been re- 
awarded and should indicate the level of priority. 
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A.2.9 Call clearing 
A.2.9.1 Mobile originated 

Figure A.4 refers. The mobile originated call clearing procedure can be started by one of the MS sending 
an up-link <U-DISCONNECT> message. The SwMI should respond to this message by sending a down- 
link <D-RELEASE> message to that mobile and that mobile should be released from the call. 
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NOTE: The SwMI may start the CC-SS retention timer. 

Figure A.4: Request to disconnect, direct or on/off hook signalling, message trunked system 

The other MS should be informed of the call clearance by a <D-DISCONNECT> message. Its response 
may be one of the following: 

1) the MS may respond by sending a <U-DISCONNECT ACKNOWLEDGE^ This should allow that 
mobile a time delay required for user interaction, such as the invoking of supplementary services. 
The MS should send a <U-RELEASE> when the user interaction has been completed and the 
mobile should be released; 

2) the MS may respond by sending a <U-RELEASE> message. This should immediately release the 
mobile from the call. 

Alternatively, the connected MS may be informed of the call clearance by a <D-RELEASE> message from 
the SwMI. This message should not be responded to. 

A.2.9.2 SwMI originated 

In the case where the SwMI cannot support a request for a call from the calling MS f the SwMI should send 
a <D-RELEASE> message, containing the reason for failure, to the calling MS. 
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In the case where the SwMI can no longer support an established call, it should send a <D-RELEASE> 
message to the calling and called MS's containing the reason for disconnection, and should subsequently 
release the call. 



A.3 Procedures - transmission trunked systems 



A.3.1 Call set-up - on/off hook signalling 



Figure A.5 refers. The call set-up request can be started by an up-link message <U-SETUP> from the MS. 
The SwMI may acknowledge the call set-up request by sending a down-link message 
<D-CALL PROCEEDING> and to indicate that the call is being processed. 
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NOTE 1 : The indication of on/off hook signalling is indicated in the D-SETUP message. 

NOTE 2: Late assignment, i.e. the traffic channel is allocated when the called user has 
answered. 



NOTE 3: Example of other signalling. 

Figure A.5: Call set-up, on/off hook signalling, transmission trunked system 

If following the receipt of a <U-SETUP> message, the SwMI determines that for some reason the call 
cannot be supported, then the SwMI should initiate call clearing as defined in subclause A.3.9. 

If the call can be supported, the SwMI should send a down-link message <D-SETUP> to the called MS to 
start the alerting process at the called mobile. It should be indicated to the called MS that on/off signalling 
is being used for this call. This message may be acknowledged by a <U-ALERT> to indicate that the 
called mobile has begun the alerting process. 
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Upon receiving an indication that the called party is alerting (<U-ALERT>), the SwMI should send a 
<D-ALERT> to the calling party. 

When the called MS answers, a <U-CONNECT> message should be sent from the called MS to the 
SwMI. 

Upon receipt of the <U-CONNECT> message the SwMI should send a <D-CONNECT> message to the 
calling MS and a <D-CONNECT ACKNOWLEDGE> to the called MS. 

Communication can commence. 

NOTE: As an implementation option the network may support intermediate signalling from the 
calling MS to the SwMI and visa versa during the call set-up phase, for the purposes of 
supplementary services et al. Similarly the network may support signalling to the called 
MS at this time. 

A.3.1 .1 Traffic assignment 

There should be one method for assigning a traffic channel: 

1) late assignment: the traffic channels should not be assigned until the called MS sends a 
<U-CONNECT> message. Upon receipt of this message the traffic channels should be indicated to 
the calling and called MS along with the <D-CONNECT> and <D-CONNECT ACKNOWLEDGE> 
messages respectively, (contained in the lower layer part of those messages). In this case the 
calling MS should remain listening on the control channel until he is told to move to the traffic 
channel. 
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A.3.2 Call set-up - direct set-up signalling 



Figure A.6 refers. The call set-up request can be started by an up-link message <U-SETUP> from the MS. 
The SwMI may acknowledge the call set-up request by sending a down-link message 
<D-CALL PROCEEDING> and to indicate that the call is being processed. 
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NOTE 1 : The request to send direct signalling is indicated in the D-SETUP message. 

NOTE 2: Late assignment, i.e. the traffic channel is allocated when the called user has 
answered. 



Figure A.6: Call set-up, direct set-up signalling, transmission trunked system 

If following the receipt of a <U-SETUP> message, the SwMI determines that for some reason the call 
cannot be supported, then the SwMI should initiate call clearing as defined in subclause A.3.9. 

If the call can be supported, the SwMI should send a down-link message <D-SETUP> to the called MS 
and it should be indicated to the called MS that direct set-up signalling is being used. This message 
should acknowledged by a <U-CONNECT> to indicate that the called mobile is able to receive the call. 

Upon receipt of the <U-CONNECT> message the SwMI should send a <D-CONNECT> message to the 
calling MS and a <D-CONNECT ACKNOWLEDGE> to the called MS. 



Communication can commence. 



A.3.2.1 Traffic channel assignment 

There should be one method for assigning a traffic channel: 



1) late assignment: the traffic channels should not assigned until the called MS sends a 
<U-CONNECT> message. Upon receipt of this message the traffic channels should be indicated to 
the calling and called MS in the <D-CONNECT> and <D-CONNECT ACKNOW LEDG E> messages 
respectively. In this case the calling MS should remain listening on the control channel until it is told 
to move to the traffic channel. 
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A.3.3 Request-to-transmit 

The SwMI should be in full control over which MS is allowed to transmit because the MS should request 
permission to transmit, and permission should be granted before the MS can do so. 

If on/off hook signalling is used, it should be normal system operation that the called MS should be given 
permission to transmit by default in the <D-SET-UP> message and late assignment may apply if 
appropriate. However, if desired, the calling MS can ask for permission to transmit in the <U-SETUP> 
message. The response to this request is dealt with in subclause A.3.4, case (1). 

If direct set-up signalling is used, it should be normal system operation that the calling MS should be given 
the permission to transmit. Traffic assignment is as previously discussed in subclause A.3.2.1 . 

For both signalling methods, when the awarded mobile has finished transmitting it should send a 
<U-TX CEASED>. Figure A.7 refers. 

Upon receipt of the <U-TX CEASED> message, the SwMI may send both MSs a <D-TX CEASED> 
message, the MSs should be cleared from the traffic channel and the SwMI can await further demands 
from the calling and called MSs. When either MS wishes to make a request to transmit, it should send a 
<U-TX DEMAND> message. The response to this request is dealt with in subclause A.3.4, case (2). 
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Figure A.7: Request to transmit, direct set-up or on/off hook signalling, transmission trunked 

system 
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A.3.4 Response to request-to-transmit 

Case 1 : if on/off hook signalling applies and the calling MS has asked for permission to transmit at the call 
set-up, the SwMI can award permission as appropriate and can respond to this request in the 
<D-CALL PROCEEDING> message. If permission is granted, then the SwMI should also inform the called 
MS in the <D-SET-UP> message that permission has not been granted to him. 

Case 2: figure A.7 refers. During any call, a <U-TX DEMAND> message may be sent by either MS. If the 
other MS is not already transmitting then the SwMI response should be a <D-TX GRANTED> message 
sent to the awarded MS, and a D-INFO sent to the other MS. The messages can be accompanied by the 
traffic channel allocation (contained in the lower layer parts), supplementary service information can also 
be appended to this message if appropriate. 

If a <U-TX DEMAND> message is sent and the other MS is already transmitting, then the SwMI should 
wait for that party to finish the transmission, (identified by the receipt of a <U-TX CEASED> message). 
Subsequently the SwMI can send a <D-TX GRANTED> message to the awarded MS and a D-INFO to the 
other MS. Priority requests are dealt with under subclause A.3.8. 

A.3.5 Permission to transmit withdrawn 

The SwMI may decide to interrupt transmission when resources are required for another call or that the 
SwMI requires that the call should temporarily pause. In this case the SwMI should send a <D-TX WAIT> 
message to both mobiles. Permission to transmit should be withdrawn, or should not be given to a 
requesting mobile. The MSs should obey channel allocation and await further instructions on the channel 
that they have been directed to. The <D-TX WAIT> should: 

confirm to the MSs that the call is in a queue; 

indicate to the MSs that they should not send further requests-to-transmit. 

If the request-to-transmit is granted but queued, the MS should be allowed to withdraw its 
request-to-transmit by means of the message <U-TX CEASED>. 

A.3.6 Permission to continue with withdrawn call 

When the SwMI has decided that the call can continue, the SwMI may send a <D-TX GRANTED> 
message to the awarded mobile and a <D-TX CONTINUE> message to the other mobile and the mobiles 
may be told to go to the traffic channel. If no mobiles have been given permission to transmit then they 
should be sent a <D-TX CONTINUE> message and should not be sent to the traffic channel. They are 
now free to make a request to the SwMI. 

A.3.7 End of transmission 

At the end of a transmission, the MS should send <U-TX CEASED>. The SwMI should send a 
<D-TX CEASED> to all concerned MS's to return them to the Control Channel. Figure A.6 refers. 

A.3.8 Stop-transmission order 

Figure A.7 refers. If, during the course of a transmission, a MS wishes to interrupt the transmitting MS with 
a higher priority request, a <U-TX DEMAND> message should be sent indicating the level of priority, the 
SwMI should send a <D-INTERRUPT> message to the transmitting MS and a <D-TX GRANTED> 
message to the requesting MS. Both messages should indicate the permission to transmit has been re- 
awarded and should indicate the level of priority. (If the SwMI wishes to change the traffic channel, then 
this instruction may also be appended to the <D-TX GRANTED> message). 

A.3.9 Call clearing 

A.3.9.1 Mobile originated 

Figure A.8 refers. The mobile originated call clearing procedure can be started by one of the MS sending 
an up-link <U-DISCONNECT> message. The SwMI should respond to this message by sending a down- 
link <D-RELEASE> message to that mobile and that mobile should be released from the call. 



Page 158 

ETS 300 392-1: February 1996 

The other MS is informed of the call clearance by a <D-DISCONNECT> message. Its response may be 
one of the following: 

1) the MS may respond by sending a <U-DISCONNECT ACKNOWLEDGE^ This should allow that 
mobile a time delay required for user interaction, such as the invoking of supplementary services. 
The MS should send a <U-RELEASE> when the user interaction has been completed and the 
mobile should be released; 

2) ' the MS may respond by sending a <U-RELEASE> message. This should immediately release the 

mobile from the call. 

Alternatively, the connected MS may be informed of the call clearance by a <D-RELEASE> message from 
the SwMI. This message should not be responded to. 

Traffic 
channel 

MS A SwMI MSB allocation 



Air Interface Air Interface 




NOTE: The SwMI may start the CC-SS retention timer. 

Figure A.8: Request to disconnect, direct set-up or on/off hook signalling, transmission trunked 

system 

A.3.9.2 SwMI originated 

In the case where the SwMI cannot support a request for a call from the calling MS, the SwMI should send 
a <D-RELEASE> message, containing the reason for failure, to the calling MS. 

In the case where the SwMI can no longer support an established call, it should send a <D-RELEASE> 
message to the calling and called MS's containing the reason for disconnection, and should subsequently 
release the call. 
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A.4 Procedures - quasi-transmission trunked systems 
A.4.1 Call set-up - on/off hook signalling 

Figure A.9 refers. The call set-up request can be started by an up-Iink message <U-SETUP> from the MS. 
The SwMI may acknowledge the call set-up request by sending a down-link message 
<D-CALL PROCEEDING> and to indicate that the call is being processed. 

If following the receipt of a <U-SETUP> message, the SwMI determines that for some reason the call 
cannot be supported, then the SwMI should initiate call clearing as defined in subclause A.4.9. 

If the call can be supported, the SwMI should send a down-link message <D-SETUP> to the called MS to 
start the alerting process at the called mobile. It should be indicated to the called MS that on/off signalling 
is being used for this call. This message may be acknowledged by a <U-ALERT> to indicate that the 
called mobile has begun the alerting process. 

Upon receiving an indication that the called party is alerting (<U-ALERT>), the SwMI should send a 
<D-ALERT> to the calling party. 
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NOTE 1 : The indication of on/off hook signalling is indicated in the D-SETUP message. 

NOTE 2: Late assignment, i.e. the traffic channel is allocated when the called user has 
answered. 

NOTE 3: Example of other signalling. 

Figure A.9: Call set-up, on/off hook signalling, quasi-transmission trunked system 
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When the called MS answers, a <U-CONNECT> message should be sent from the called MS to the 
SwMI. 

Upon receipt of the <U-CONNECT> message the SwMI should send a <D-CONNECT> message to the 
calling MS and a <D-CONNECT ACKNOWLEDGE> to the called MS. 

Communication can commence. 

NOTE: As an implementation option the network may support intermediate signalling from the 
calling MS to the SwMI and visa versa between the <D-ALERT> message and the 
<D-CONNECT> message for the purposes of supplementary services et al. Similarly 
the network may support signalling to the called MS at this time. 

A.4.1 .1 Traffic assignment 

There should be one method for assigning a traffic channel: 

1) late assignment: the traffic channels should not be assigned until the called MS sends a 
<U-CONNECT> message. Upon receipt of this message the traffic channels should be indicated to 
the calling and called MS along with the <D-CONNECT> and <D-CONNECT AC KNOW LEDG E> 
messages respectively, (contained in the lower layer part of those messages). In this case the 
calling MS remains listening on the control channel until he is told to move to the traffic channel. 

A.4.2 Call set-up - direct set-up signalling 

Figure A.10 refers. The call set-up request can be started by an up-link message <U-SETUP> from the 
MS. The SwMI may acknowledge the call set-up request by sending a down-link message 
<D-CALL PROCEEDING> and to indicate that the call is being processed. 
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NOTE 1 : The request to send direct signalling is indicated in the D-SETUP message. 

NOTE 2: Late assignment, i.e. the traffic channel is allocated when the called user has 
answered. 

Figure A.10: Call set-up, direct set-up signalling, quasi-transmission trunked system 

If following the receipt of a <U-SETUP> message, the SwMI determines that for some reason the call 
cannot be supported, then the SwMI should initiate call clearing as defined in subclause A.4.9. 
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If the call can be supported, the SwMI should send a down-link message <D-SETUP> to the called MS 
and it should be indicated to the called MS that direct set-up signalling is being used. This message 
should be acknowledged by a <U-CONNECT> to indicate that the called mobile is able to receive the call. 

Upon receipt of the <U-CONNECT> message the SwMI should send a <D-CONNECT> message to the 
calling MS and a <D-CONNECT ACKNOWLEDGE> to the called MS. 

Communication can commence. 

A.4.2.1 Traffic assignment 

There should be one method for assigning a traffic channel: 

1) late assignment: the traffic channels should not be assigned until the called MS sends a 
<U-CONNECT> message. Upon receipt of this message the traffic channels should be indicated to 
the calling and called MS along with the <D-CONNECT> and <D-CONNECT ACKNOWLEDGE> 
messages respectively, (contained in the lower layer part of those messages). In this case the 
calling MS should remain listening on the control channel until he is told to move to the traffic 
channel. 
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A.4.3 Request-to-transmit 
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Figure A.1 1 : Request to transmit, direct set-up or on/off hook signalling, quasi-transmission 

trunked system 

The SwMl should be in full control over which MS is allowed to transmit because the MS should request 
permission to transmit, and permission should be granted before the MS can do so. 
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If on/off hook signalling is used, it should be normal system operation that the called MS should be given 
permission to transmit by default in the <D-SET-UP> message and early, medium or late assignment 
should apply as appropriate. However, if desired, the calling MS can ask for permission to transmit in the 
<U-SETUP> message. The response to this request is dealt with in subclause A.4.4, case 1 . 

If direct set-up signalling is used, it should be normal system operation that the calling MS should be given 
the permission to transmit. Traffic assignment should as previously discussed in subclause A.4.2.1 . 

For both signalling methods, when the awarded mobile has finished transmitting it should send a 
<U-TX CEASED>. Figure A.11 refers. 

Upon receipt of the <U-TX CEASED> message, the SwMI should start a timer (hang time) and should 
send the receiving MS a <D-INFO> to inform that the transmission from the other MS has now ceased. 
After expiry of the timer, and no MSs have sent any messages, the SwMI should send both mobiles the 
<D-TX CEASED> message which informs both mobiles to leave the traffic channel and that they are able 
to request permission to transmit. Any MS may explicitly request for permission to transmit by sending a 
<U-TX DEMAND> message. The response to this request should be determined by whether the Timer 
has expired or not and is dealt with in subclause A.4.4, case 2. 

If the hang-time is infinite the TETRA may become message trunked. 

A.4.4 Response to request-to-transmit 

Case 1 : if on/off hook signalling applies and the calling MS has asked for permission to transmit at the call 
set-up, the SwMI can award permission as appropriate and should respond to this request in the 
<D-CALL PROCEEDING> message. If permission is granted, then the SwMI should also inform the called 
MS in the <D-SET-UP> message that permission has not been granted to him. 

Case 2: figure A.1 1 refers. During any call, a <U-TX DEMAND> message may be sent by either MS. If the 
other MS is not already transmitting and the timer has expired, then the SwMI response should be a 
<D-TX GRANTED> message sent to the awarded MS, and a D-INFO sent to the other MS. The 
messages should contain the traffic channel assignment. Supplementary service information can also be 
appended to this message if appropriate. 

If a <U-TX DEMAND> message is sent when no MS is transmitting but the hang timer has not expired, 
then the SwMI response may be a <D-TX GRANTED> message sent to the awarded MS and a D-INFO to 
the other MS. The MSs are assumed to be still on the traffic channel and a new assignment need not be 
given. 

If a <U-TX DEMAND> message is sent and the other MS is already transmitting, then the SwMI should 
wait for that party to finish the transmission, (identified by the receipt of a <U-TX CEASED> message). 
Subsequently the SwMI should send a <D-TX GRANTED> message to the awarded MS and a D-INFO to 
the other MS. The MSs are assumed to be still on the traffic channel and a new assignment need not be 
given. Priority requests are dealt with under subclause A.4.8. 

A.4.5 Permission to transmit withdrawn 

The SwMI may decide to interrupt transmission when resources are required for another call or that the 
SwMI requires that the call should temporarily pause. In this case the SwMI should send a <D-TX WAIT> 
message to both mobiles. Permission to transmit should be withdrawn, or should not be given to a 
requesting mobile. The MSs should obey channel allocation and await further instructions on the channel 
that they have been directed to. The use of this message is optional. Figure A.11 refers. The 
<D-TX WAIT> should: 

confirm to the MSs that the call is in a queue; 

indicate to the MSs that they should not send further requests-to-transmit. 

If the request-to-transmit is granted but queued, the MS is allowed to withdraw its request-to-transmit by 
means of the message <U-TX CEASED>. 
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A.4.6 Permission to continue with withdrawn call 

When the SwMI has decided that the call can continue, the SwMI may send a <D-TX GRANTED> 
message to the awarded mobile and a <D-TX CONTINUE> message to the other mobile and the mobiles 
may be told to go to the traffic channel. If no mobiles have been given permission to transmit then they 
should be sent a <D-TX CONTINUE> message and are free to make a request to the SwMI. 

A.4.7 End of transmission request 

At the end of a transmission, the MS should send <U-TX CEASED> and should listen to the traffic 
channel. Upon receipt of the <U-TX CEASED> message, the SwMI should start a timer (hang time) and 
should send a <D-INFO> message to the other MS to indicate that the transmission has ceased.. After 
expiry of the timer, and no MSs have sent any messages, the SwMI should send both mobiles the 
<D-TX CEASED> message which should inform both mobiles to leave the traffic channel and go to the 
control channel. Figure A.11 refers. 

A.4.8 Stop-transmission order 

If, during the course of a transmission, the other mobile wishes to interrupt the transmitting mobile with a 
higher priority request and sends a <U-TX DEMAND> message indicating the level of priority, the SwMI 
should send a <D-TX CEASED> message to both mobiles followed by a <D-TX GRANTED> message to 
both mobiles re-awarding permission to the requesting mobile and indicating the level of priority to both 
mobiles. 

A.4.9 Call clearing 
A.4.9.1 Mobile originated 
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NOTE: The SwMI may start the CC-SS retention timer. 

Figure A.12: Request to disconnect, quasi-transmisslon trunked system 



Page 165 

ETS 300 392-1 : February 1996 



Figure A.12 refers. The mobile originated call clearing procedure can be started by one of the MS sending 
an up-link <U-DISCONNECT> message. The SwMI should respond to this message by sending a down- 
link <D-RELEASE> message to that mobile and that mobile should be released from the call. 

The other MS should be informed of the call clearance by a <D-DISCONNECT> message. Its response 
may be one of the following: 

1) the MS may respond by sending a <U-DiSCONNECT ACKNOWLEDGE^ This should allow that 
mobile a time delay required for user interaction, such as the invoking of supplementary services. 
The MS should send a <U-RELEASE> when the user interaction has been completed and the 
mobile should be released; 

2) the MS may respond by sending a <U-RELEASE> message. This should immediately release the 
mobile from the call. 

Alternatively, the connected MS may be informed of the call clearance by a <D-RELEASE> message from 
the SwMI. This message should not be responded to. 

A.4.9.2 SwMI originated 

In the case where the SwMI cannot support a request for a call from the calling MS, the SwMI should send 
a <D-RELEASE> message, containing the reason for failure, to the calling MS. 

In the case where the SwMI can no longer support an established call, it should send a <D-RELEASE> 
message to the calling and called MSs containing the reason for disconnection, and should subsequently 
release the call. 
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Annex B (informative): Group voice call scenarios 
B.1 Procedures for message trunked systems 
B.1.1 General 

All group calls are considered as employing only direct set-up signalling procedures. This procedure 
allows immediate communication to take place between the calling and called users without the necessity 
of having an alerting process and without an explicit response from the called user that he has answered. 
The called users normally go straight to the traffic channel. 

For acknowledged group calls, it is an operator option if the call is to proceed immediately by giving the 
originator permission to transmit. Alternatively, the operator may choose to poll the MS on the traffic 
channel and act according upon the receipt of a response from the polled MS. 

NOTE 1 : This procedure is known as presence checking. 

According to a predefined criteria the call may be allowed to proceed. 

It is an operator option to disconnect the call if insufficient members are present, and the right to transmit 
has not yet been given. 

It is an operator option to continue with presence checking beyond the point where the originator has been 
given permission to transmit. 

NOTE 2: For clarity, the time sequence diagrams in this clause only show two participating 
members of the group call. 
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B.1.2 Call set-up 
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NOTE 1: Early assignment, Le, the calling MS and the called MS may be sent to the traffic 



NOTE 2: Late assignment, i.e., the calling MS may be sent to the traffic channel at this stage. 

NOTE 3: For acknowledged group calls, the presence of the members of the group may be 
indicated here. 

Figure B.1 : Call set-up phase for a group call in a message trunked system 

The call set-up request is started by an up-link message <U-SETUP> from the MS. The SwMI may 
optionally acknowledge the call set-up request by sending a down-link message <D-CALL 
PROCEEDING> to indicate that the call is being processed, (see figure B.1). 

If, following the receipt of a <U-SETUP> message, the SwMI determines that for some reason the call 
cannot be supported, then the SwMI initiates call clearing as defined in subclause B.1. 9. 

If the call can be supported, the SwMI sends a down-link message(s) <D-SETUP> to the called MS. 

During, or as an option upon completion of, the transmission of the <D-SETUP> message, the SwMI may 
send a <D-CONNECT> message to the calling MS. 

On completion of this procedure communication can commence. 

The option depends upon whether the group call is an acknowledged one. If it is acknowledged, the SwMI 
may delay the transmission of the <D-CONNECT> message to the calling MS, and wait for 
acknowledgements from the called MS before proceeding. If at this stage the SwMI decides that the call 
cannot be supported it initiates call clearing as defined in subclause B.1 .9. 

If the group call is acknowledged, the call owner may be informed of the presence of the other members 
of the group in the <D-INFO> message. 



channel at this stage. 
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B.1 .2.1 Traffic channel assignment 

For the called MS, the traffic channel assignment is always given in the <D-SET-UP> message. 
There are two methods for assigning a traffic channel to the calling MS: 

1 ) early assignment: the traffic channel is assigned and indicated to the calling MS along with the 
<D-CALL PROCEEDING^ (contained in the lower layer part of that message). In this case the 
calling MS moves immediately to the channel that has been made available as the future traffic 
channel, and receives all further call control messages on this channel in anticipation of the call; or 

2) late assignment: the traffic channel is not assigned until appropriate conditions are met. 

NOTE: These conditions may be as a result of the finite time required to locate group 
members, or as a result of the call being acknowledged. In this case the calling MS 
remains listening on the control channel (or other if instructed by the SwMI) ( until it is 
told to move to the traffic channel. The traffic channel is indicated to the calling MS 
along with the <D-CONNECT> message, (contained in the lower layer part of that 
message). 

B.1 .3 Request-to-transmit 

The SwMI is in full control over which MS is allowed to transmit because the MS is obliged to request 
permission to transmit, and permission must be granted before the MS can do so. 

It is normal system operation that the calling MS will be given the permission to transmit immediately upon 
call set-up. Traffic channel assignment is as previously discussed in subclause B.1 .2. 

When the awarded MS has finished the communication it sends a <U-TX CEASED>, (see figure B.2). 

Upon receipt of the <U-TX CEASED> message, the SwMI sends a <D-INFO> message to the "receiving" 
MS to inform them that the transmission has now ceased. The SwMI awaits further demands from the 
calling and called MS. When any MS wishes to make a request to transmit, it sends a <U-TX DEMAND> 
message. The response to this request is dealt with in subclause B.1 .4. 
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NOTE: D-TX granted is sent to the remaining members of the group upon awarding 
permission to MS B. 

Figure B.2: Request to transmit for a group call in a message trunked system 



B.1 .4 Response to request-to-transmit 

During any call, a <U-TX DEMAND> message may be sent by any MS. If any other MS is not already 
transmitting, then the SwMl may response with a <D-TX GRANTED> message sent to the awarded MS 
addressed by his Individual TETRA Subscriber Identity (ITSI), and a D-<INFO> sent to the remaining MS 
addressed by the Group TETRA Subscriber Identity (GTSI), (see figure B.2). 

If a <U-TX DEMAND> message is sent and another MS is already transmitting, then the SwMl waits for 
that MS to finish it's transmission, (identified by the receipt of a <U-TX CEASED> message). 
Subsequently the SwMl sends a <D-TX GRANTED> message to the requesting MS addressed by his 
ITSI, awarding permission to transmit, and a <D-lNFO> message to the remaining MS, addressed by the 
GTSI. Priority requests are dealt with under subclause B.1 .8. 



B.1 .5 Permission to transmit withdrawn 



The SwMl may decide to interrupt transmission when resources are required for another call or that the 
SwMl requires that the call should temporarily pause. In this case the SwMl sends a <D-TX WAIT> 
message to all MS. Permission to transmit is be withdrawn, or is not given to a requesting MS. The MS 
should obey channel allocation and await further instructions on the channel that they have been directed 
to. The <D-TX WAIT> will: 



confirm to the MS that the call is in a queue; 



indicate to the MS that they may not send further requests-to-transmit. 



If the request-to-transmit is granted but queued, the MS is allowed to withdraw its request-to-transmit by 
means of the message <U-TX CEASEDx 
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B.1 .6 Permission to continue with withdrawn call 

When the SwMI has decided that the call can continue, the SwMI sends a <D-TX GRANTED> message 
to the awarded MS, addressed by his ITSI, and a <D-TX CONTINUE> message to all remaining MS, 
addressed by the GTSI. The MS are told to go to the traffic channel. 

If no MS have been given permission to transmit then they are sent a <D-TX CONTINUE> message and 
are free to make a request to the SwMI. 

B.1 .7 End of transmission 

At the end of a communication, the MS sends <U-TX CEASED> and listens to the traffic channel, (see 
figure B.2). The SwMI sends <D-INFO> to all participants addressed by the GTSI to inform them that the 
transmission has now ceased. 

B.1. 8 Stop-transmission order 

If, during the course of a transmission, a MS wishes to interrupt the transmitting MS with a higher priority 
request, a <U-TX DEMAND> message is sent indicating the level of priority, the SwMI sends a 
<D-INTERRUPT> message to the transmitting MS addressed by his ITSI, a <D-TX GRANTED> message 
to the awarded MS, addressed by his ITSI and a <D-INFO> to all other MS, addressed by the GTSI. All 
messages indicate that the permission to transmit has been re-awarded and should indicate the level of 
priority, (see figure B.2). 

B.1. 9 Call clearing 

B.1 .9.1 Mobile originated 



MS A Air Interface SwMI Air Interface MS B channel 
, i 1 i 1 allocation 




NOTE: The SwMI may start the CC-SS retention timer. 

Figure B.3: Call clearing for a group call in a message trunked system 

The call owner may disconnect the call at any stage of the call, (see figure B.3). Only the call owner can 
complete this operation. The MS originated call clearing procedure is started by the call owner sending an 
up-link <U-DISCONNECT> message. The SwMI responds to this message by sending a down-link 
<D-RELEASE> message to all MS and they are released from the call. 
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B.1.9.2 SwMI originated 

In the case where the SwMI cannot support a request for a call from the calling MS, the SwMI sends a 
<D-RELEASE> message, containing the reason for failure, to the calling MS. 

In the case where the SwMI can no longer support an established call, it sends a <D-RELEASE> 
message to all MS, containing the reason for disconnection, and subsequently releases the call. 

B.2 Procedures for transmission trunked systems 
B.2.1 General 

All group calls are considered as employing only direct set-up signalling procedures. This procedure 
allows immediate communication to take place between the calling and called users without the necessity 
of having an alerting process and without an explicit response from the called user that he has answered. 
The called users normally go straight to the traffic channel. 

For acknowledged group calls, it is an operator option if the call is to proceed immediately by giving the 
originator permission to transmit. Alternatively, the operator may choose to poll the MS on the traffic 
channel and act according upon the a response from the polled MS. 

NOTE 1 : This procedure is known as presence checking. 

According to a predefined criteria the call may be allowed to proceed. 

It is an operator option to disconnect the call if insufficient members are present, and the right to transmit 
has not yet been given. 

It is an operator option to continue with presence checking beyond the point where the originator has been 
given permission to transmit. 

NOTE 2: For clarity, the time sequence diagrams in this clause only show two participating 
members of the group call. 

B.2.2 Call set-up 

The call set-up request is started by an up-link message <U-SETUP> from the MS. The SwMI may 
optionally acknowledge the call set-up request by sending a down-link message 
<D-CALL PROCEEDING> and to indicate that the call is being processed, (see figure B.4). 

If following the receipt of a <U-SETUP> message, the SwMI determines that for some reason the call 
cannot be supported, then the SwMI may initiate call clearing as defined in subclause B.1 .9. 

If the call can be supported, the SwMI sends a down-link message <D-SETUP> to the called MS. 

During, or as an option upon completion of, the transmission of the <D-SETUP> message, the SwMI 
sends a <D-CONNECT> message to the calling MS. 

On completion of this procedure communication can commence. 
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NOTE 1 : Late assignment, i.e. the called MS are sent to the traffic channel at this stage. 
NOTE 2: The calling MS is sent to the traffic channel at this stage. 

NOTE 3: For acknowledged group calls, the presence of the members of the group may be 
indicated here. 

Figure B.4: Call set-up phase for a group call in a transmission trunked system 

The option depends upon whether the group call is an acknowledged one. If it is acknowledged, the SwMI 
may delay the transmission of the <D-CONNECT> message to the calling MS, and wait for 
acknowledgements from the called MS before proceeding. If at this stage the SwMI decides that the call 
cannot be supported it may initiate call clearing as defined in subclause B.1 .9. 

If the group call is acknowledged, the call owner may be informed of the presence of the other members 
of the group in the <D-INFO> message. 

B.2.2.1 Traffic channel assignment 

For the called MS, the traffic channel assignment is given in the <D-SET-UP> message. 

There is one method for assigning a traffic channel to the calling MS: 

late assignment: the traffic channel is not assigned until appropriate conditions are met. (These 
conditions may be as a result of the finite time required to locate group members, or as a result of 
the call being acknowledged.) The traffic channel is indicated to the calling MS along with the 
<D-CONNECT> message, (contained in the lower layer part of that message). In this case the 
calling MS remains listening on the control channel (or other channel if instructed by the SwMI) until 
he is told to move to the traffic channel. 

B.2.3 Request-to-transmit 

The SwMI is in full control over which MS is allowed to transmit because the MS is obliged to request 
permission to transmit, and permission must be granted before the MS can do so. 



It is normal system operation that the calling MS is given the permission to transmit immediately upon call 
set-up. Traffic channel assignment is as previously discussed in subclause B.2.2.1 . 
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When the awarded MS has finished the communication it sends a <U-TX CEASED>, (see figure B.5). 

Upon receipt of the <U-TX CEASED> message, the SwMI sends all MS a <D-TX CEASED> message, the 
MS obey channel allocation and the SwMI awaits further demands from the calling and called MS. When 
any MS wishes to make a request to transmit, it sends a <U-TX DEMAND> message. The response to 
this request is dealt with in subclause B.2.4. 
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NOTE: D-TX granted is sent to the remaining members of the group upon awarding 
permission to MS B. 

Figure B.5: Request to transmit for a group call in a transmission trunked system 
B.2.4 Response to request-to-transmit 

During any call, a <U-TX DEMAND> message may be sent by any MS. If any other MS is not already 
transmitting, then the SwMI response should be a <D-TX GRANTED> message sent to the awarded MS 
addressed by his ITSI and a <D-INFO> sent to the remaining MS addressed by the GTSI. The message 
may be accompanied by the traffic channel allocation (contained in the lower layer parts). Supplementary 
service information may also be appended to these messages if appropriate (see figure B.5). 

If a <U-TX DEMAND> message is sent and another MS is already transmitting, then the SwMI should wait 
for that party to finish the transmission, (identified by the receipt of a <U-TX CEASED> message). 
Subsequently the SwMI sends a <D-TX GRANTED> message to the requesting MS, addressed by his 
ITSI, awarding permission to transmit to him and a <D-INFO> message to the remaining MS, addressed 
by the GTSI. (If the SwMI wishes to change the traffic channel, then this instruction may also be appended 
to the <D-TX GRANTED> and <D-INFO> messages.) Priority requests are dealt with in subclause B.2.8. 
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B.2.5 Permission to transmit withdrawn 

The SwMI may decide to interrupt transmission when resources are required for another call or that the 
SwMI requires that the call should temporarily pause. In this case the SwMI sends a <D-TX WAIT> 
message to all MS. Permission to transmit is withdrawn, or is not given to a requesting MS. The MS 
should obey channel allocation and await further instructions on the channel that they have been directed 
to. 

If the request-to-transmit is granted but queued, the MS is allowed to withdraw its request-to-transmit by 
means of the message <U-TX CEASED>. The <D-TX WAIT> will: 

confirm to the MS that the call is in a queue; 

indicate to the MS that they may not send further requests-to-transmit. 

B.2.6 Permission to continue with withdrawn call 

When the SwMI has decided that the call can continue, the SwMI sends a <D-TX GRANTED> message 
to the awarded MS, addressed by his ITSI, and a <D-TX CONTINUE> message to all remaining MS 
addressed by the GTSI. The MS are then told to go to the traffic channel. 

On the other hand, If no MS have been given permission to transmit then they may be sent a 
<D-TX CONTINUE> message and are not sent to the traffic channel. They are free to make a request to 
the SwMI. 

B.2.7 End of transmission 

At the end of a transmission, the MS sends <U-TX CEASED>. The SwMI sends a <D-TX CEASED> to all 
MS's to return them to the control channel, (unless another MS has asked for permission to transmit, see 
subclause B.2.4 and figure B.5). 

B.2.8 Stop-transmission order 

If, during the course of a transmission, a MS wishes to interrupt the transmitting MS with a higher priority 
request, a <U-TX DEMAND> message is sent indicating the level of priority, the SwMI sends a 
<D-INTERRUPT> message to the transmitting MS addressed by his ITSI, a <D-TX GRANTED> message 
to the awarded MS, addressed by his ITSI and a <D-INFO> to all other MS, addressed by the GTSI. All 
messages indicate that the permission to transmit has been re-awarded and indicate the level of priority. 
(If the SwMI wishes to change the traffic channel, then this instruction may also be appended to the 
<D-TX GRANTED>, <D-INTERRUPT> and <D-INFO> messages), (see figure B.5). 

B.2.9 Call clearing 

B.2.9.1 Mobile originated 

The call owner may disconnect the call at any stage of the call, (see figure B.6). Only the call owner can 
complete this operation. The MS originated call clearing procedure is started by the call owner sending an 
up-link <U-DISCONNECT> message. The SwMI may respond to this message by sending a down-link 
<D-RELEASE> message to all MS and they are released from the call. 
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NOTE: The SwMI may start the CC-SS retention timer. 

Figure B.6: Call clearing for a group call in a transmission trunked system 
B.2.9.2 SwMI originated 

In the case where the SwMI cannot support a request for a call from the calling MS, the SwMI may send a 
<D-RELEASE> message, containing the reason for failure, to the calling MS. 

In the case where the SwMI can no longer support an established call, it may send a <D-RELEASE> 
message to all MS, containing the reason for disconnection, and subsequently release the call. 

B.3 Procedures for quasi-transmission trunked systems 

B.3.1 General 

All group calls are considered as employing only direct set-up signalling procedures. This procedure 
allows immediate communication to take place between the calling and called users without the necessity 
of having an alerting process and without an explicit response from the called user that he has answered. 
The called users normally go straight to the traffic channel. 

For acknowledged group calls, it is an operator option if the call is to proceed immediately by giving the 
originator permission to transmit. Alternatively, the operator may choose to poll the MS on the traffic 
channel and act according upon the receipt of a response form the polled MS. 

NOTE 1 : This procedure is known as presence checking. 

According to a predefined criteria the call may be allowed to proceed. 

It is an operator option to disconnect the call if insufficient members are present, and the right to transmit 
has not yet been given. 

it is an operator option to continue with presence checking beyond the point where the originator has been 
given permission to transmit. 

NOTE 2: For clarity, the time sequence diagrams in this clause only show two participating 
members of the group call. 
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B.3.2 Call set-up 

The call set-up request is started by an up-link message <U-SETUP> from the MS. The SwMI may 
optionally acknowledge the call set-up request by sending a down-link message 
<D-CALL PROCEEDING> and to indicate that the call is being processed, (see figure B.7). 

If following the receipt of a <U-SETUP> message, the SwMI determines that for some reason the call 
cannot be supported, then the SwMI initiates call clearing as defined in subclause B.3.9. 

If the call can be supported, the SwMI sends a down-link message <D-SETUP> to the called MS. 

During, or as an option upon completion of, the transmission of the <D-SETUP> message, the SwMI may 
send a <D-CONNECT> message to the calling MS. 

On completion of this procedure communication can commence. 



MSA Air Interface SwMI Air Interface MSB Tratt)C 

channel 

I I i | allocation 




NOTE 1 : Late assignment, i.e. the called MS are sent to the traffic channel at this stage. 
NOTE 2: The calling MS is sent tot he traffic channel at this stage. 

NOTE 3: For acknowledged group calls, the presence of the members of the group may be 
indicated here. 

Figure B.7: Call set-up phase for a group call in a quasi-transmission trunked system 

The option depends upon whether the group call is an acknowledged one. If it is acknowledged, the SwMI 
may delay the transmission of the <D-CONNECT> message to the calling MS, and wait for 
acknowledgements from the called MS before proceeding. If at this stage the SwMI decides that the call 
cannot be supported it initiates call clearing as defined in subclause B.3.9. 



If the group call is acknowledged, the call owner may be informed of the presence of the other members 
of the group in the <D-INFO> message. 
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B.3.2.1 Traffic channel assignment 



For the called MS, the traffic channel assignment is always given in the <D-SET-UP> message. There is 
one method for assigning a traffic channel to the calling MS: 

late assignment: the traffic channel is not assigned until appropriate conditions are met. (These 
conditions may be as a result of the finite time required to locate group members, or as a result of 
the call being acknowledged.) The traffic channel is indicated to the calling MS along with the 
<D-CONNECT> message, (contained in the lower layer part of that message). In this case the 
calling MS remains listening on the control channel until he is told to move to the traffic channel. 



B.3.3 Request-to-transmit 
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Figure B.8: Request to transmit for a group call in a quasi-transmission trunked system 
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The SwMI is in full control over which MS is allowed to transmit because the MS is obliged to request 
permission to transmit, and permission must be granted before the MS can do so. 

It is normal system operation that the calling MS will be given the permission to transmit immediately upon 
call set-up. Traffic channel assignment is as previously discussed in subclause B.3.2.1 . 

When the awarded MS has finished the communication it sends a <U-TX CEASED>, (see figure B.8). 

Upon receipt of the <U-TX CEASED> message, the SwMI starts a timer (hang time) and sends a 
<D-INFO> message to the "receiving" MS to inform them that the transmission has now ceased. After 
expiry of the timer, and no MS have sent any messages, the SwMI may send all MS a <D-TX CEASED> 
message, the MS should obey channel allocation and the SwMI awaits further demands from the calling 
and called MS. When any MS wishes to make a request to transmit, he sends a <U-TX DEMAND> 
message. The response to this request is dealt with in subclause B.3.4. 

If the hang time is infinite the TETRA system becomes message trunked. 

B.3.4 Response to request-to-transmit 

During any call, a <U-TX DEMAND> message may be sent by any MS. If any other MS is not already 
transmitting, and the hang timer has expired, then the SwMI response is a <D-TX GRANTED> message 
sent to the awarded MS addressed by his ITSI and a <D-INFO> message sent to the remaining MS 
addressed by the GTSI. The message should be accompanied by the traffic channel allocation (contained 
in the lower layer parts). Supplementary service information may also be appended to these messages if 
appropriate (see figure B.8). 

If a <U-TX DEMAND> message is sent when no MS is transmitting, but the hang timer has not expired, 
then the SwMI response is a <D-TX GRANTED> message sent to the awarded MS addressed by his ITSI 
awarding permission to transmit to him, and a <D-INFO> message sent to the remaining MS addressed 
by the GTSI. The MS are assumed to be still on the traffic channel and a new assignment is not 
necessarily given. 

If a <U-TX DEMAND> message is sent and another MS is already transmitting, then the SwMI should wait 
for that party to finish the transmission, (identified by the receipt of a <U-TX CEASED> message). 
Subsequently the SwMI sends a <D-TX GRANTED> message, to the requesting MS, addressed by his 
ITSI, awarding permission to transmit to him, and a <D-INFO> message to the remaining MS, addressed 
by the GTSI. (If the SwMI wishes to change the traffic channel, then this instruction may also be appended 
to the <D-TX GRANTED> and <D-INFO> messages.) Priority requests are dealt with under 
subclause B.3.8. 

B.3.5 Permission to transmit withdrawn 

The SwMI may decide to interrupt transmission when resources are required for another call or that the 
SwMI requires that the call should temporarily pause. In this case the SwMI sends a <D-TX WAIT> 
message to all MS. Permission to transmit is withdrawn, or is not given to a requesting MS. The MS 
should obey channel allocation and should await further instructions on the channel that they have been 
directed to. The <D-TX WAIT> will: 

confirm to the MS that the call is in a queue; 

indicate to the MS that they may not send further requests-to-transmit. 

If the request-to-transmit is granted but queued, the MS is allowed to withdraw its request-to-transmit by 
means of the message <U-TX CEASED>. 

B.3.6 Permission to continue with withdrawn call 

When the SwMI has decided that the call can continue, the SwMI should send a <D-TX GRANTED> 
message to the awarded MS, addressed by his ITSI, and a <D-TX CONTINUE> message to all remaining 
MS addressed by the GTSI. The MS are told to go to the traffic channel. 
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On the other hand, If no MS have been given permission to transmit then they are sent a 
<D-TX CONTINUE> message and are not sent to the traffic channel. They are free to make a request to 
the SwMI. 

B.3.7 End of transmission 

At the end of a transmission, the MS sends <U-TX CEASED> and listens to the traffic channel. Upon 
receipt of the <U-TX CEASED> message, the SwMI starts a timer (hang time) and sends a <D-INFO> 
message to the "receiving" MS to inform them that the transmission has now ceased. After expiry of the 
timer, and no MS have sent any messages, the SwMI sends ail MS, addressed by the GTSI, the 
<D-TX CEASED> message which informs the MS to obey channel allocation and await further instructions 
on the channel that they have been directed to, (see figure B.8). 

B.3.8 Stop-transmission order 

If, during the course of a transmission, a MS wishes to interrupt the transmitting MS with a higher priority 
request, a <U-TX DEMAND> message is sent indicating the level of priority, the SwMI sends a 
<D-INTERRUPT> message to the transmitting MS addressed by his ITSI, a <D-TX GRANTED> message 
to the awarded MS, addressed by his ITSI, and a <D-INFO> to all other MS addressed by the GTSI. All 
messages should indicate the permission to transmit has been re-awarded and should indicate the level of 
priority. (If the SwMI wishes to change the traffic channel, then this instruction may also be appended to 
the <D-TX GRANTED> and <D-INFO> messages), (see figure B.8). 

B.3.9 Call clearing 

B.3.9.1 Mobile originated 

The call owner may disconnect the call at any stage of the call, (see figure B.9). Only the call owner can 
complete this operation. The MS originated call clearing procedure is started by the call owner sending an 
up-Iink <U-DISCONNECT> message. The SwMI responds to this message by sending a down-link 
<D-RELEASE> message to all MS and they are released from the call. 
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NOTE: The SwMI may start the CC-SS retention timer. 

Figure B.9: Call clearing for a group call in a quasi-transmission trunked system 
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B.3.9.2 SwMI originated 

In the case where the SwMI cannot support a request for a call from the calling MS, the SwMI should send 
a <D-RELEASE> message, containing the reason for failure, to the calling MS. 

In the case where the SwMI can no longer support an established call, it should send a <D-RELEASE> 
message to all MS, containing the reason for disconnection, and subsequently release the call. 
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Annex C (informative): Priority functions for circuit mode services 
C.1 Introduction 



This annex covers only the priority functions for circuit mode calls in the TETRA voice and data standard. 
It describes the priority requirements. This annex identifies the mechanisms which can be available to 
TETRA users and operators in order to achieve their priority requirements. 

Priority information may used by both the TETRA network operators and TETRA users in order to ensure 
that quality of service objectives can be met. This annex recognises 6 identifiable priority requirements, 
any one of which or any combination of which may be requested in order to meet the demands of the 
users and networks. The selection of priority requirements may be seen as a network implementation. 

The layers in the air interface protocol stack can exchange priority information with the following entities: 



the layer above; 
the layer below; 
the peer entity; 



the LLME. 



This arrangement is shown schematically in figure C.1 . 
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Figure C.1 : Sources and destinations of priority information 
C.2 Priority requirements 

These should be the priority requirements of the TETRA system as perceived by the user and operator. 
Generally any individual user should only be aware of three levels of priority; normal, high and emergency. 

C.2.1 Access priority 

There can be methods of controlling the access of subscribers to the system during times of congestion. 
The controlling methods should allow favourable access on a pre-defined measure of quality. 
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C.2.2 Call type priority 

The operator may elect to have equal or unequal priority attributed to the type of call. 

EXAMPLE 1: A speech group call may take priority over an individual call, speech calls over 

data calls etc. 

Different subscribers on the same system may have different call type priority requirements. 

EXAMPLE 2: Fleet 1 may elect secure voice to be a higher priority than fleet 1 data calls, 

however fleet 2 may have different requirements. 

C.2.3 Queue priority 

Queue priority can be related to queuing for any limited resource in the network (e.g. down-link air 
interfaces, leased lines, access to databases etc.). The attribution of a measure of quality can enable the 
limited resources to be allocated to the queuing subscribers on a priority basis rather than e.g. on a first 
come first served basis. 

C.2.4 Pre-emptive priority 

Pre-emptive priority allows any resource that is being used to be freed for a call of pre-emptive priority. 
The resource may be any resource controlled by the TETRA system. 

EXAMPLE 1: During times of high system loading, existing calls may be cleared to provide 

resource for calls with priority to warrant this action. 

EXAMPLE 2: Existing calls may be cleared to allow a pre emptive priority call to be made to a 

terminal that was engaged in the existing call. 

C.2.5 Call retention priority 

Call retention priority should define the relative level of protection of a call (once established) against the 
pre-emption of its network connection. 

C.2.6 Subscriber priority 

The priority of a call may be associated with the subscriber. 

EXAMPLE: Within a fleet, certain subscribers by virtue of their position within that 

organisation may automatically have a higher priority for their calls than other 
members of that fleet occupying a different position within the same 
organisation. 

C.3 Mechanisms for supporting priority 

There can be a number of mechanisms available to the operator and to the user for supporting priority. 
Each mechanism can support several methods. 

Those available to the operator are: 

1 ) layer 2 access broadcast; 

2) layer 3 system broadcast. 
Those available to the user are: 

supplementary service activation and Invocation. 

NOTE: There is no distinction made between CC message and supplementary service 
messages in this ETS. 
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C.3.1 Supplementary service activation and invocation 

The network operator may offer users the ability to activate and invoke supplementary services. Generally, 
TETRA supplementary services may be activated by the user only when he has subscribed to them, 
however some operators may wish to make the supplementary services available on a general basis. In 
the event where the user should firstly subscribe to the supplementary service, the service may be 
permanently activated, so that for example, when the user indicates to the network that he wishes to make 
a call, the supplementary service should be automatically invoked. 

Alternatively a supplementary service may be invoked with a facility information element contained within a 
CC, call maintenance or facility message. 

The supplementary services that are of interest to priority are: 

1 ) access priority; 

2) priority call; 

3) pre-emptive priority call; 



4) call retention. 
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Annex D (informative): Quality of Service (QoS) 
D.1 Introduction 

This annex is largely based on IS0.8348 [12] (which is equivalent to CCITT Recommendation X.213 [9]). 
These two documents have the same section numbering. 

Some sections have been shortened, where it was felt that the information was of lower importance, and 
readers should therefore refer back to these source documents for more details if required. 

Some parts of this annex have been specially drafted for TETRA. These sublauses are clearly marked as 
not having any equivalent in the IS0.8348 [12] (or CCITT Recommendation X.213 [9]) source documents. 

This annex describes the network connection QoS parameters that will be required for services in TETRA. 

The annexes define a number of parameter values based on what is likely to be achievable. 

The QoS refers to those characteristics that are observed between the network connection endpoints. The 
annex is largely based on IS0.8348 [12] and CCITT Recommendation X.213 [9], but has been modified to 
suit the requirements of TETRA. 

D.2 Quality of network service 

Refer to IS0.8348 [12] (or CCITT Recommendation X.213 [9]) clause 10. 

Quality of network service refers to certain characteristics of a Network Connection (NC) as observed 
between the NC endpoints. QoS describes aspects of an NC which are attributable solely to the Network 
Service (NS) provider; it can only be properly determined in the absence of NS user behaviour (which is 
beyond the control of the NS provider) that specifically constrains or impairs the performance of the 
network service. 

A value of QoS applies to an entire NC. When determined or measured at both ends of an NC, the QoS 
observed by the NS user at the two ends of the NC is the same. This is true even in the case of an NC 
spanning several subnetworks where each subnetwork offers different services. 

The term quality of service also refers to certain characteristics of a network connectionless-mode 
transmission as observed between a pair of NSAPs. QoS describes aspects of a network connectionless- 
mode transmission which are attributable solely to the NS provider; it can only be properly determined in 
the absence of NS user behaviour (which is beyond the control of the NS provider) that specifically 
constrains or impairs the performance of the network service. 

Whether the view of the QoS during each instance of the use of the network connectionless-mode 
transmission is the same to each NS user associated with the service depends on the nature of their 
association and the type of information concerning the nature of the service that is made available to the 
NS user(s) by the NS provider prior to the invocation of the service. 

D.2.1 Determination of quality of network service 

Refer to IS0.8348 [12] (or CCITT Recommendation X.213 [9]) subclause 10.1 . 

QoS is described by means of QoS parameters. The definition of each of these QoS parameters specifies 
the way in which the QoS parameters value is measured or determined, making reference (where 
appropriate) to primitive events of the NS. 

Information about the QoS is exchanged among the NS provider and NS users in terms of QoS 
parameters. 
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D.2.1 .1 Connection oriented quality of network service 

Connection oriented QoS parameters can be classified as: 

1) those which are conveyed between peer NS users by means of the NS during the establishment 
phase of an NC. As part of this conveyance a three-party negotiation may take place among the NS 
users and the NS provider, for the purpose of agreeing upon a particular QoS parameter value; 

2) those values which are not conveyed, (i.e. they are purely requested by the NS user from the NS 
provider). For these QoS parameters, however, information about the values which is useful to the 
NS provider and each NS user may be made known by local means. 

The connection oriented NS QoS parameters are defined in subclause D.2.3. 

D.2.1 .2 Connectionless quality of network service 

A basic characteristic of a connectionless mode service is that no peer-to-peer negotiation of the QoS for 
a transmission takes place at the time that the service is accessed. No dynamic association is set up 
between the parties involved as during a NC establishment; thus, characteristics of the service to be 
provided during the transfer are not negotiated on a peer-to-peer basis. An a priori agreement is assumed 
to exist between the NS users and the NS provider concerning those parameters, formats and options that 
affect the transfer of data. 

The NS QoS parameters associated with each network connectionless-mode transmission are described 
in subclause D.2.1 3. 

D.2.2 QoS negotiation and non-negotiation 

Refer to IS0.8348 [12] (or CCITT Recommendation X.213 [9]) subclause 12.2.7. 

QoS parameters may be negotiated or non-negotiated. The negotiation is between the NS users and the 
NS provider. Non-negotiated parameters apply to both directions of data transfer. Negotiated parameters 
may be different for each direction of data transfer. Negotiation takes the form of a QoS parameter set, 
where each parameter has a set of "sub-parameters" defined from the following possibilities; 

a) a target value which is the QoS value desired by the calling user; 

b) the lowest quality acceptable value which is the lowest QoS value agreeable to the calling user; 

c) an available value which is the QoS value that the network is willing to provide; 

d) a selected value which is the QoS value to which the called user agrees. 
D.2.3 QoS parameter set for connection oriented services 

D.2.3.1 Summary 

Refer to IS0.8348 [12] (or CCITT Recommendation X.213 [9]) subclause 10.2. 
The connection oriented QoS parameters may be classified as: 

a) QoS parameters which express network service performance; 

b) QoS parameters which express other network service characteristics. 
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The following tables summarise the QoS parameters: 



Table D.1 : Classification of performance QoS-parameters 



Phase 


Perfor 

Speed 


mance Criterion 

Accuracy/Reliability 


NC establishment 


NC establishment delay 


NC establishment failure probability 


Data transfer 


Throughput 
Transit delay 


Residual error rate 

NC resilience 

Transfer failure probability 


NC release 


NC release delay 


NC release failure probability 



Table D.2: QoS-parameters not associated with performance 



NC protection 
NC priority 
Maximum acceptable cost 
NC resilience 



D.2.3.2 NC establishment delay 

Refer to IS0.8348 [12] (or CCITT Recommendation X.213 [9]) subclause 10.2.1 . 

NC establishment delay is the maximum acceptable delay between a TN-CONNECT request and the 
corresponding TN-CONNECT confirm primitive. 

D.2.3.3 NC establishment failure probability 

Refer to IS0.8348 [12] (or CCITT Recommendation X.213 [9]) subclause 10.2.2. 

NC establishment failure probability is the ratio of total NC establishment failures to total NC 
establishment attempts in a measurement sample. 

NC establishment failure is defined to occur when a requested NC is not established within the maximum 
acceptable time period as a result of NS provider behaviour such as misconnection, NC refusal, or 
excessive delay. NC establishment attempts which fail as a result of NS user behaviour such as error, NC 
refusal, or excessive delay are excluded in calculating NC establishment failure probability. 

NOTE: This parameter is defined in terms of establishment failure as reported at the network 
layer service boundary. Certain lower layer failures may not contribute to this failure 
probability (e.g. if the protocol includes automatic recovery procedures). 

D.2.4 Throughput (User information transfer rate) 

D.2.4.1 Throughput for constant delay services 

Refer to IS0.8348 [12] (or CCITT Recommendation X.213 [9]) subclause 10.2.3. 

Throughput is defined, for each direction of transfer, as the maximum rate the NS provider can 
continuously sustain, when unconstrained by flow control applied by the receiving NS user. 

Given a sequence of n NSDUs (where n is greater than or equal to 2), throughput is defined to be the 
smaller of: 

a) the number of NS-user data octets contained in the last (n-1) NSDUs divided by the time between 
the first and last TN-DATA requests in the sequence; and 

b) the number of NS-user data octets contained in the last (n-1) NSDUs divided by the time between 
the first and last TN-DATA indications in the sequence. 
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Successful transfer of the octets in a transmitted NSDU is defined to occur when the octets are delivered 
to the intended receiving NS user(s) without error, in the proper sequence, prior to release of the NC by 
the receiving NS user. 

Throughput is specified separately for each direction of transfer. Each throughput specification will specify 
both the desired "target" value and the minimum acceptable value (i.e. the "lowest quality acceptable") for 
the NC. 

D.2.4.2 Throughput for variable delay services 

This parameter does not appear in IS0.8348 [12] or CCITT Recommendation X.213 [9J. 

Throughput for variable delay services differs from the constant delay case due to the existence of 
automatic retransmission protocols. 

Throughput for variable delay services defines the average user data rate that can be achieved over the 
relevant service coverage area. This average throughput should be expected to reduce for operation 
outside the stated coverage area. 

NOTE: The actual throughput that is achieved may be further reduced by certain user 
protocols (e.g. synchronous modems). The stated figure will only be achieved with 
ideal user protocols. 

D.2.5 Transit delay 

D.2.5.1 Transit delay for constant delay services 

Refer to IS0.8348 [12] (or CCITT Recommendation X.213 [9]) subclause 10.2.4. 

Transit delay is the elapsed time between a TN-DATA request and the corresponding TN-DATA 
indication. Elapsed time values are calculated only on NSDUs that are successfully transferred. 

Successful transfer of an NSDU is defined to occur when the NSDU is transferred from the sending NS 
user to the intended receiving NS user without error, in the proper sequence, prior to release of the NC by 
the receiving NS user. 

Specification of transit delay will define a pair of values: the desired "target" value and the maximum 
acceptable value (i.e. the "lowest quality acceptable"). The specified values will be averages and will be 
based on an NSDU size of 128 octets. 

The pair of transit delay values specified for an NC applies to both directions of transfer. That is, the 
transit delay in each direction is expected to be no worse than that specified. 

D.2.5.2 Transit delay for voice services 

Transit delay for voice services shall be based on the definition for a constant delay service, where the 
NSDU is defined to be a single speech frame. 

Transit delay for voice services shall be specified in terms of the one way delay time corresponding to a 
single transmission across the air interface. 

D.2.5.3 Transit delay for variable delay services 

This parameter does not appear in IS0.8348 [12] or CCITT Recommendation X.213 [9]. 

Transit delay for variable delay services can vary due to the existence of automatic retransmission 
protocols. 

Transit delay for variable delay services refers to the delay that will apply under ideal conditions, when no 
automatic retransmissions have occurred. Any automatic retransmissions will increase this delay. 
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D.2.6 Residual error rate 

Refer to IS0.8348 [12] (or CCITT Recommendation X.213 [9]) subclause 10.2.5. 

The residual error rate (RER) is the ratio of total incorrect, lost and duplicate NSDUs to total NSDUs 
transferred across the NS boundary during a measurement period. The RER may be represented by the 
following formula; 

RER = We) + N(H + N(x) 
N 

where: 

N is the total number of NSDUs transferred; 
N(e) is the number of incorrect NSDUs received; 
N(l) is the number of NSDUs lost; 
N(x) is the number of extra NSDUs received. 
D.2.7 Transfer failure probability 

Refer to IS0.8348 [12] (or CCITT Recommendation X.213 [9]) subclause 10.2.6. 

Transfer failure probability is the ratio of total transfer failures to total transfer samples during a 
performance measurement. 

A transfer sample is a discrete observation of NS provide performance in transferring NSDUs between a 
specified sending and receiving user. A transfer sample begins on input of a selected NSDU at the 
sending NS user boundary, and continues until the outcome of a given number of NSDU transfer requests 
has been determined. A transfer sample will normally correspond to the duration of an individual NC. 

A transfer failure is a transfer sample in which the observed performance is worse than a specified 
minimum acceptable level. Transfer failures are identified by comparing the measured values for 
performance parameters with specified failure thresholds. The three supported performance parameters 
are throughput, transit delay and residual error rate. 

In systems where QoS is reliably monitored by the NS provider, transfer failure probability can be 
estimated by the probability of an NS provider invoked TN-DISCONNECT during a transfer sample. 

This parameter shall only apply to packet mode services. 

D.2.8 NC resilience 

Refer to IS0.8348 [12] (or CCITT Recommendation X.213 [9]) subclause 10.2.7. 
NC resilience parameters specify the probability of: 

a) an NS provider invoked NC release (i.e., issuance of an TN-DISCONNECT indication with no prior 
TN-DISCONNECT request); and 

b) an NS provider invoked reset (i.e. issuance of a TN-RESET indication with no prior TN-RESET 
request); 

during a specified time interval on an established NC. 
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D.2.8.1 NC release delay 

D.2.8.1 .1 NC release delay at the peer user 

Refer to IS0.8348 [12] (or CCITT Recommendation X.213 [9]) subclause 10.2.8. 

NC release delay at the peer user is the maximum acceptable delay between an NS user invoked 
TN-DISCONNECT request and the successful release of the NC at the peer NS user. NS release delay 
does not apply in cases where NC release is invoked by the NS provider. 

Issuance of a TN-DISCONNECT request by either NS user starts the counting of the NC release delay for 
the other NS user. Successful NC release is signalled to the NS user not initiating the TN-DISCONNECT 
request by a TN-DISCONNECT indication. 

D.2.8.1 .2 NC release delay at the invoking user 

This parameter does not appear in IS0.8348 [12] or CCITT Recommendation X.213 [9]. 

NC release delay at the invoking user is the maximum acceptable delay between an NS user invoked 
TN-DISCONNECT request and the successful acknowledgement of the release of the NC at that same 
NS user. NS release delay does not apply in cases where NC release is invoked by the NS provider. 

Issuance of a TN-DISCONNECT request by either NS user starts the counting of the NC release delay for 
the other NS user. Successful NC release is signalled to the NS user initiating the TN-DISCONNECT 
request by a TN-DISCONNECT confirmation. 

D.2.8.2 NC release failure probability 

Refer to IS0.8348 [12] (or CCITT Recommendation X.213 [9]) subclause 10.2.9. 

NC release failure probability is the ratio of total NC release requests resulting in NC release failure to 
total NC release requests included in a measurement sample. NC release failure probability is normally 
specified independently for each NS user. 

A release failure is defined to occur, for a particular NS user, if that user does not receive a 
TN-DISCONNECT indication within the specified maximum NC release delay of the NS user issuing the 
TN-DISCONNECT request (given that the former NS user has not issued a TN-DISCONNECT request). 

This will only be specified as a network performance figure. 

D.2.8.3 NC protection 

Refer to IS0.8348 [12] (or CCITT Recommendation X.213 [9]) subclause 10.2.10. 

NC protection is the extent to which an NS provider attempts to prevent unauthorised masquerading or 
monitoring or manipulation of NS-user-data. NC protection for an NC is specified by selecting any 
combination of the following features: 

a) confidentiality of an entire NSDU sequence on the NC; 

b) detection of modification, deletion, replay, or insertion of data within the NSDU sequence on an NC; 

C ) p eer entity authentication. The NS user may request that the NS provider should confirm the identity 
of the remote NSAP such that there is protection against masquerading T-entities; 

d) authentication of the origin of an NSDU such that there is protection against the unauthorised 
insertion or replay of the NSDU; 

e) authentication of the NS provider to guard against masquerading entities. 
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D.2.8.4 NC priority 

Refer to ISO.8348 [12] (or CCITT Recommendation X.213 [9]) subclause 10.2.1 1 . 

NC priority specified independently the relative importance of an NC with respect to the following: 

a) priority to gain an NC; 

b) priority to keep an NC; 

c) priority of data on the NC. 

NC priority QoS-parameters a) and b) together define the order in which the NCs are broken to recover 
resources if necessary. The NS provider is required to accept new requests for NCs with a high priority 
type a) if it can, even if NCs with a lower priority b) have to be released to do so. 

NC priority QoS-parameter c) defines the order in which NCs have their QoS degraded. The NCs with a 
high priority c) are to have their requests serviced within the required QoS first and remaining resources 
are then used to satisfy requests on lower priority NCs. 

D.2.9 Maximum acceptable cost 

Refer to ISO.8348 [12] (or CCITT Recommendation X.213 [9]) subclause 10.2.12. 

The maximum acceptable cost QoS-parameter specifies the maximum acceptable cost for an NC. The 
cost may be specified in absolute or relative cost units. The cost of an NC is composed of 
communications and end-system resource costs. 

D.2.1 0 Air interface parameters 

These parameters do not appear in ISO.8348 [12] or CCITT Recommendation X.213 [9]. Therefore they 
are only applicable to circuit-mode services. 

D.2.1 0.1 Duration of interruption of user traffic due to call restoration 

The duration of interruption of user traffic due to call restoration is the total time for which a traffic channel 
is interrupted due to a single call restoration event. If there are several short interruptions during this 
process, the sum total of all these interruptions shall apply. 

Different figures may apply depending on the type of the call restoration. The following different cases are 
identified: 

change of cell; 

change of RF carrier at the same cell (with or without a change of slot position); 
change of slot position on the same RF carrier at the same cell. 
D.2.1 0.2 Call restoration success rate 

The call restoration success rate is the probability of a call restoration being successful within a defined 
service coverage area. A successful call restoration is defined to occur when all established calls are 
maintained. 

D.2.1 0.3 Interruption of user traffic due to slot stealing 

This parameter should shall only apply to circuit-mode services. 

This parameter should specify the duration of any single continuous interruption of user traffic due to slot 
stealing, and the interval between successive interruptions. 
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D.2.1 1 Supplementary service parameters 

D.2.1 1 .1 Maximum time to activate a supplementary service 

This parameter does not appear in IS0.8348 [12] or CCITT Recommendation X.213 [9]. 
This parameter should only apply to circuit mode services. 

The maximum time to activate a supplementary service is the time from the issuing of the service request 
to the time when the service has become available. 

D.2.1 2 Connection oriented QoS negotiation 

The initial negotiation between NS user and NS provider utilises the QoS-parameter set field in the 
TN-CONNECT request message. This will contain both "target" and "lower quality acceptable" values. The 
NS provider will send the QoS-parameter set with the "available" values in the TN-CONNECT confirm 
message. Where negotiation involves the called party, the TN-CONNECT indication message includes 
the "target" and "lower quality acceptable" values that are agreeable to the NS provider (and the calling 
NS user). The TN-CONNECT response includes the "selected" value. The "selected" value is transmitted 
to the calling user in the TN-CONNECT confirm message. 

D.2.1 3 QoS parameter set for connectionless services 

D.2.1 3.1 Summary 

Connectionless QoS parameters can be classified as: 

1) those which are fixed in advance: either fixed characteristics of the network (i.e. non-negotiable) or 
negotiated in advance of the packet submission; 

2) those which are requested at the time of packet submission (i.e. they are purely requested by the 
NS user from the NS provider on a per-packet basis). 

The QoS parameters can be further classified as: 

a) QoS parameters which express network service performance; 

b) QoS parameters which express other network service characteristics. 
The following tables summarise the connectionless QoS parameters: 



Table D.3: Classification of performance QoS-parameters 



Phase 


Perfor 

Speed 


nance Criterion 

Accuracy/Reliability 


Data transfer 


Transit delay 


Residual error probability 



Table D.4: QoS-parameters not associated with performance 



Protection from unauthorised access 

Cost determinants 
Priority 
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D.2.13.2 Transit delay 

Refer to IS0.8348/Addendum 1 [12], subclause 10.3.1. 

Connectionless packet transit delay is the elapsed time between a TN-UNITDATA request and the 
corresponding TN-UNITDATA indication. Elapsed time values are calculated only on NSDUs that are 
successfully transferred. 

Successful transfer of an NSDU is defined to occur when the NSDU from the sending NS user is delivered 
to the intended receiving NS user without error. 

Transit delay should be specified independently for each network connectionless-mode transmission. 
Transit delay defines the value expected for the completion of the transmission of a particular NSDU. Its 
specification should be based on an average NSDU size. It should be determined by the NS provider and 
made known to the NS user prior to the invocation of the service. 

Transit delay for an individual NSDU may be greatly increased if local interface flow control is exercised at 
either the transmitting or receiving service provider to service user interface. Occurrences of local 
interface flow control should be excluded in calculating transit delay values. 

D.2.1 3.3 Protection from unauthorised access 

Refer to IS0.8348/Addendum 1 [12], subclause 10.3.2. 

The extent to which a NS provider attempts to prevent unauthorised monitoring or manipulation of NS 
user-originated information is specified qualitatively by selecting one of four options: 

a) no protection features; 

b) protection against passive monitoring; 

c) protection against modification, replay, addition and deletion; and 

d) both (b) and (c). 

D.2.1 3.4 Cost determinants 

Refer to IS0.8348/Addendum 1 [12], subclause 10.3.3. 

A class of parameter values and options may exist which provide a NS user with: 

a) the ability to indicate to the NS provider that it should choose, for example, the least expensive 
means available to it, even in situations where this may not be the most expedient means; or 

b) the ability to specify maximum acceptable cost. 

The cost may be specified in absolute or relative cost units. The cost of a network connectionless-mode 
transmission is composed of communications and end system costs. 

D.2.1 3.5 Residual error probability 

Refer to IS0.8348/Addendum 1 [12], subclause 10.3.4. 

Residual error probability describes the likelihood that a particular NSDU will be lost, duplicated, or 
delivered incorrectly. This probability is estimated as the ratio of lost, duplicated, or incorrectly delivered 
NSDUs to the total NSDUs transmitted by an NS provider during a measurement period. 

An incorrectly delivered NSDU is one in which the user data are delivered in a corrupted condition, or the 
user data are delivered to an incorrect NSAP. 

Lost data includes all NSDUs which are discarded by the NS provider due to congestion, transmission 
error, or some other error. NSDUs which are lost due to error by the NS user are not included. 
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D.2.13.6 Priority 

Refer to IS0.8348/Addendum 1 [12], subclause 10.3.5. 

This parameter allows the NS user to specify the relative priority of an NSDU in relation to any other 
NSDUs acted upon by the NS service provider. An NSDU of higher priority is serviced by the NS provider 
before one of lower priority. The priority information is conveyed to the receiving NS user. 

This parameter specifies the relative importance of network connectionless-mode transmission with 
respect to: 

a) the order in which NSDUs are to have their quality of service degraded, if necessary; and 

b) the order in which NSDUs are to be discarded to recover resources, if necessary. 

This parameter has meaning only in the context of some management entity or structure able to judge 
relative importance. The number of priority levels is limited to 15. 

D.2.13.7 Connectionless QoS negotiation 

Not applicable. 
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D.3 Applicability of QoS parameters to TETRA services 



Table D.5: Applicability of connection oriented QoS-parameters 





CONS 


cct data 


cct data 


voice 






protected 


unprotected 




NC establishment delay 


n 


n 


n 


f 


NC establishment failure probability 


s 


s 


s 


s 


Throughput 


N 


N 


N 


f 


Transit delay 


n 


f 


f 


f 


Residual error rate 


n 


n1 


f 


f 


Transfer failure prob. 


s 


s 


s 


s 


NC resilience 


s 


s 


s 


s 


NC release delay 


s 


s 


s 


s 


NC release failure prob. 


s 


s 


s 


s 


NC protection 


N 


N 


N 


N 




note 2 


note 2 


note 2 


notes 










2 and 3 


NC priority 


n 


n 


n 


n 




note 4 


note 4 


note 4 


note 4 


Maximum acceptable cost 


n 


n 


n 


n 




note 2 


note 2 


note 2 


note 2 



Table D.6: Applicability of connectionless QoS-parameters 





S-CLNS 


SDS 


Transit delay 


s 


s 


Protection from unauthorised access 


n 


n 


Cost determinants 


n 


n 




note 2 


note 2 


Residual error probability 


s 


s 


Priority 


n 


n 




notes 


note 4 




4 and 5 





Key and notes: 

f fixed relative to type of call; 

n negotiable only between NS user and NS provider; 

N negotiable between NS users (calling and called) and NS provider; 

s network performance figure; 

x not applicable/not specified. 

NOTE 1 : Not applicable to unprotected services. 

NOTE 2: May not be implemented on all systems. 

NOTE 3: Negotiable only between calling NS user and NS provider for point-to-multipoint calls. 

Called NS users not able to meet protection requirements will be excluded from the 
call. 

NOTE 4: The negotiation only uses a limited set of parameters (see subclause D.2.8.4). 
NOTE 5: Negotiation only supported by full version of S-CLNS. 
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